On Sun, 17 May 2009, Linus Torvalds wrote:
On Sun, 17 May 2009, Linus Torvalds wrote:
That said, on my laptops, CPU time really _never_ is the issue. Every
single time something is slow, the issue is a slow 4200rpm disk that may
get 25MB/s off it for linear things in the best case, but seeks take
milliseconds and any kind of random access will just kill performance.
Side note - I've several times desperately tried to see if IO parallelism
helps. It doesn't. Some drives do better if they get many independent
reads and can just do them concurrently. Sadly, that's pretty rare for
reads on rotational media, and impossible with legacy IDE drives (that
don't have the ability to do tagged queueing).
So when I try to do IO in parallel (which git does support for many
operations), that just makes the whole system come to a screeching halt
because it now seeks around the disk a lot more. A similar issue that
often kill parallelism on CPU's (bad cache behavior, and lots of
outstanding memory requests) kills parallelism on disks too - disk
performance simply is much _better_ if you do serial things than if you
try to parallelize the same work.
It would be different if I had a fancy high-end RAID system with tagged
queueing and lots of spare bandwidth that could be used in parallel. But
that's not what the git usage scenario often is. All the people pushing
multi-core seem to always ignore the big issues, and always working on
nice trivial problems with a small and well-behaved "kernel" that has no
IO and preferably didn't cache well even when single-threaded (ie
"streaming" data).
do things change with SSDs? I've heard that even (especially??) with the
Intel SSDs you want to have several operations going in paralllel to get
the best out of them.
David Lang
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html