Re: [boost] [1.58.0] Release candidates available

Subject: Re: [boost] [1.58.0] Release candidates available
From: Bjørn Roald (bjorn_at_[hidden])
Date: 2015-04-07 18:03:47

On 07. april 2015 22:33, Vladimir Prus wrote:
> On 04/07/2015 10:42 PM, Bjørn Roald wrote:
>
>> Also, in principle, bjam could check available free RAM before
>> invoking a new parallel task.  I think -j 4 does not mean it _has_ to
>> run 4
>> tasks in parallel, rather it means up to 4 tasks in paralell.  An
>> implicit -j <hardware_concurrency> certainly should throttle on system
>> resources, so why not available RAM as well as available cores.
>
> I don't think it's easy. If I run 4 compilations in parallel, and it
> consumes so much RAM and I/O that computer becomes
> unresponsive, it means the OS could not throttle these tasks
> effectively.

The OS can not throttle a running process' greediness for RAM, at least 
I don't think so. It could prevent new processes to start, but that is 
also tricky for the OS in a general sense. This is however trivial for a 
build system when deciding whether it should start additional parallel 
compiler invocations that are totally optional tuning for build speed. 
It make no sense to start additional compilations in parallel if you see 
the physical RAM is consumed.  The tricky part is knowing when to stop 
adding parallel tasks to prevent getting in a consumed RAM state in the 
first place.  And hopefully still leave ample space for the rest of the 
system to live.

Shooting from the hip here, why not require at least 2G of free RAM to 
start a task running in parallel.  2G may seem excessively defensive, 
but it provide good margins and who around here have dev. boxes with 
less than 8G RAM these days.

--
Bjørn