[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FYI: coreutils/gnulib-tests to run in parallel
From: |
Jim Meyering |
Subject: |
Re: FYI: coreutils/gnulib-tests to run in parallel |
Date: |
Fri, 13 Jun 2008 12:34:48 +0200 |
Ralf Wildenhues <address@hidden> wrote:
> * Jim Meyering wrote on Fri, Jun 13, 2008 at 10:17:36AM CEST:
>> Ralf Wildenhues <address@hidden> wrote:
>> > Just ordering the build of some huge objects in GCC allowed to shave 30%
>> > build time off a parallel build:
>>
>> Yes, I did the same with coreutils/tests, and it made a big difference,
>> since there were some long-running tests near the end of the initial list.
>> Here it was the first thing I tried, once parallelized. However, in
>> this case it gave less than 1 second decrease. No big surprise, though,
>> since even removing the top 4-5 longest-running tests shaves only ~8
>> seconds off the total (~11s) run time, now that they're run in parallel.
>
> IIRC most of the coreutils tests are pretty I/O bound. Running them in
> parallel won't help much, with all of them competing for the same kernel
> resp. disk resources. I guess the proposed parallel Autotest patches
> are thus limited, too. I found testing them on tmpfs (/dev/shm) to show
> much more favorable speedup than disk or NFS. You probably may want to
> ensure to have a recent kernel, too (although I have no idea whether
> there were significant improvements in in-kernel parallelism recently).
I've been talking about two groups of tests: coreutils/tests (300+,
they've been parallelized for a couple months, takes ~75s), and those that
coreutils automatically pulls in from gnulib, coreutils/gnulib-tests,
and for which "make check" (in that subdirectory) takes only 11s on a
fast dual-core system. Not worth any more tuning, there, imho ;-)
FYI, I'm using a range of kernels, but always test at least on the
latest ones from rawhide, one of which is currently 2.6.25.4-30.fc9.x86_64.