Show 14 quoted lines
> Linus Torvalds wrote:
>> And
>> the preloading sounds like it hits serialization overhead in the kernel,
>> which I'm not at all surprised at, but not being surprised doesn't mean
>> that I'm not interested to hear where it is.
>>
>> The Linux VFS dcache itself should scale better than that (but who knows -
>> cacheline ping-pong due to lock contention can easily cause a 10x slowdown
>> even without being _totally_ contended all the time). So I would _suspect_
>> that it's some NFS lock that you're seeing, but I'd love to know more.
>>
>> Btw, those system times are pretty high to begin with, so I'd love to know
>> kernel version and see a profile even without the parallel case and
>> presumably lock contention.
Here's an strace of 'git checkout':
Before (cold cache):
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
98.60 6.365501 111 57432 lstat64
0.50 0.031984 359 89 2 close
0.25 0.015818 115 137 77 open
0.12 0.007670 23 339 write
0.09 0.005631 110 51 munmap
0.08 0.004873 49 99 69 stat64
0.07 0.004771 140 34 15 access
0.05 0.003083 280 11 5 waitpid
0.05 0.002973 10 284 brk
0.04 0.002816 469 6 execve
<snip>
After (cold cache, no lstat fix, just cache_preload):
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
90.90 23.717981 413 57432 lstat64
8.72 2.273917 162423 14 2 futex
0.12 0.032241 948 34 close
0.04 0.011507 202 57 munmap
0.04 0.009648 132 73 mmap2
0.03 0.008508 149 57 20 open
0.03 0.007771 311 25 mprotect
0.03 0.007758 388 20 clone
0.03 0.007548 23 334 write
0.02 0.005247 262 20 10 access
-brandon
Brandon Casey <casey@nrlssc.navy.mil>