Prev: How do I ignore the changes made by CVS keyword substitution efficiently?
Next: [patch 3/4] fs: scale files_lock
From: Nick Piggin on 4 Jun 2010 03:30
OK, I realised what I was smoking last time. So I put down the pipe and
went to score some stronger crack. And then:
- reduced ifdefs as much as feasible
- add more comments, avoided churn
- vastly improved lock library code, works with lockdep
- added helpers for file list iterations
- lglock type for what was previously open coded in file list locking

It looks in much better shape now I hope. Al would you consider them?

With all patches applied, I ran some single threaded microbenchmarks, and it
was difficult to tell much difference from the noise. I don't claim that there
is no slowdown because there is more instructions and memory accesses for SMP.
But it doesn't seem too bad.

Opteron, ran each test 30 times. Each run lasts for 3 seconds performing as
many operations as possible. Between each 10 runs, a rebooted. After all that
you still get artifacts, oh well.

Difference at 95.0% confidence (times, positive means patch is slower)
dup/close No difference proven at 95.0% confidence
open/close -2.48989% +/- 0.538414%
creat/unlink 3.14688% +/- 0.32411%



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 | 
Pages: 1
Prev: How do I ignore the changes made by CVS keyword substitution efficiently?
Next: [patch 3/4] fs: scale files_lock