Re: make -j in Debian packages
On Fri, Jun 30, 2006 at 03:26:15AM +0200, Goswin von Brederlow wrote:
> Adam Borowski <kilobyte@angband.pl> writes:
> > Still, the buildd admin has no way to estimate how much a sub-process
> > of a package is going to use, the maintainer has at least a rough
> > idea. Since the maintainer's action is needed anyway, he can as well
> > provide this estimate.
> > And then the buildd admin can set CONCURRENCY_LEVEL to 1 to centrally
> > disable any parallelism of this kind.
>
> One could patch make to use concurency when the ram permits. This
> would involves checking the current ram usage and forking more builds
> if there is enough
Oh, so you mean checking the _free_ RAM instead of the _physical_ RAM?
This would be reasonable -- I didn't use this in the debian/rules
snippet I proposed as the physical memory is a trivially discernable
number while free RAM can be sometimes hard to tell, especially on Xen:
Mem: 588472k total, 574028k used, 14444k free, 4k buffers
Swap: 1048568k total, 24k used, 1048544k free, 238984k cached
this is on a box where the only currently accessed process is mutt
(+sshd and $EDITOR). Who cares if apache's processes which didn't
handle a single request in two months (the real server is elsewhere)
are in the physical memory? Who cares about idle dovecot? The box
is for all practical purposes completely idle as of right now.
Of course, when I say that something is tricky, it doesn't mean that
someone with more clue than me can't do it.
> as well as suspending submakes when swapping starts. But i guess
> that would greatly complicate make itself.
Actually, make -l already does something very similar. It stops -j
from forking any new processes (above 1) once the system load exceeds
a given value. And while the "system load" is a lousy measure, make
won't ever starve off the build, it will in the worst case behave as
make -j1, which is what Ingo wants.
Cheers and schtuff,
--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.
Reply to: