Re: [TEST] make -j patch [take 2]

In message <20041112115824.GA85834_at_ip.net.ua>, Ruslan Ermilov writes:

>> >> that is a long running regression test that I don't want to occupy my=
>=20
>> >> 4 processor machine, but I want the tool for the test to build fast.
>> >>=20
>> >Here's the patch that changes the -j behavior the way I want it:
>>=20
>> I think that patch is a bad idea.
>>=20
>Care to explain?

I have explained this several times already:  You should just leave
the submakes on their own and let them balance as they see fit.

I spent a lot of time on parallel/clustered make for a customer and
the outcome of that is very clear:  Leave the stuff alone after you
have said your overall intention.

Obviously you are not going to trust me on this, since you seem to
have very strong ideas on how you think it works in practice, even
though you don't seem to have any actual data to back it up with.

I suggest that you actually try out your ideas in _practice_, not
just with a few "proof of concept" makefiles made for the purpuse,
but try to actually _run_ it on real world jobs for some weeks while
you carefully gater statistics and examine the interactions between
the parameters given, where given, resulting time to build and
loading of the machine(s).

At the very least, do not commit your patch until you have managed
to come up with at least one instance of real world data where it
is a good idea.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk_at_FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.