Re: make: dynamic scaling of maxJobs ?

["Simon J. Gerraty" <sjg%juniper.net@localhost>]

On Tue, 6 Aug 2013 19:09:07 +0100, David Laight writes:
>On Fri, Aug 02, 2013 at 03:45:19PM -0700, Simon Gerraty wrote:
>> Note: This only applies to the initial instance of make, the sub-makes
>> get a normal -j value - being the maxJobTokens value in effect when they
>> are started.  The theory being that the sub-makes don't run long enough
>> to be a serious issue.
>
>The sub-makes should all take tokes out of the token queue created

Yes.  The trick is to adjust that queue on the fly, to fairly share the
machine as different users start additional builds.

>If you are soing a netbsd build, the outer make doesn't actually

No, I'm not doing a traditional bsd build - as in no tree walks.
In my build the top-level make is the only thing driving the build,
it runs a sub-make in each leaf dir directly based on a graph of the
entire tree's dependencies.  Thus the level of recursion is
very shallow and with the exception of libc or a kernel the sub-makes
run from level 0, do not run long enough to matter.

>run many different things - probably only one child make for
>every sub directory - so it won't recalculate the number of tokens
>very often (if at all).

In my case the top-level (0) make is the only one than needs to care
about this, depending on the target it may run 10000+ sub-makes over a
number of hours.   Thus it gets many chances to adjust maxJobTokens,
and the results suggest it works well.

>I actually suspect it might be better looking at why the current
>version of netbsd gets unresponsive under load.

That would be useful, but what I'm talking about isn't netbsd specific.
Oversubscription of cpu affects any OS.
As noted my colleague was testing this on a linux box with 32 cores.
FreeBSD (and I assume NetBSD we weren't able to run a test) 
did not scale well on NUMA machines like that even without
oversubscription.

--sjg