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

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: May 10, 2009, 16:50 UTC
Message-ID: <alpine.LFD.2.01.0905100943370.3586@localhost.localdomain>
In-Reply-To: <7v8wl5613c.fsf@alter.siamese.dyndns.org>

On Sat, 9 May 2009, Junio C Hamano wrote:

Show 9 quoted lines

>
> 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