Re: [PATCH] Avoid unnecessary 'lstat()' calls in 'get_stat_data()'

[Linus Torvalds <torvalds@linux-foundation.org>]

On Sat, 9 May 2009, Junio C Hamano wrote:
>
> I have been processing the patches in my "after 1.6.3" mailbox from the rc
> freeze period and have already queued this one, but the re-integration of
> four branches is taking a bit longer than usual.  It takes too much time
> to run tests (and as a part of my build procedure I do docs, too) for all
> integration branches, and until they all pass tests on Debian5 (primary
> development box) and Fedora9 (at k.org) I do not push the result out, so
> it is a bit painful for me to replace a patch once a day's testing cycle
> begins.

Heh.

I can attest from personal experience that if some test-sequence takes a 
couple of hours, and keeps you from making sane changes from the source, 
you'll eventually go mad. It was one of the reasons I absolutely hated 
working with CVS at transmeta - not only did the pre-checking tests take 
forever, but you effectively couldn't do anything else while they were 
running due to the whole "branches don't work".

Now, at least you don't have _that_ issue, but if testing keeps you from 
doing the sane thing, you'll still end up having some of the same things 
happen.

I've found that "make -j64 test" does fairly well, bringing the cost down 
to something reasonable. Some of the SVN tests seem to sometimes randomly 
fail when done in parallel (I've not tried to debug it, I assume it's 
either some SVN bug, or just the test infrastructure having some shared 
SVN central repo thing), but it happens rarely enough that even if you 
have to run it twice, it's still worth it. 

[ Side note: the success output of "make test" makes it almost impossible 
  to debug the error cases when you do that "make -j64" thing. Sad. It 
  would be good to have the tests that fail clearly say exactly what test 
  failed, because when you run 64 tests at the same time, having "case 9" 
  fail is almost totally useless information - test 9 of _which_ 
  testsuite? ]

I don't generally build docs, but they should run in parallel too, and at 
least your fedora build on kernel.org has a nice quad-core machine with 
lots of memory, so "-j8" or something is reasonable.

				Linus