On Wed, Apr 18, 2012 at 06:26:58PM -0500, Amit Kulkarni wrote: > > This is very cheap to compute, this just requires an extra wrapper-process > > around make to compute those numbers. > > > > Stuff > 300000 more or less corresponds to VMEM_WARNING ports. > > > > One thing worth doing will be to set a threshold in dpb, and not allow > > two "large" ports to build at the same time on a single host (just by > > looking at the next ports in the queue, plenty of candidates usually) > > Err. you will look at ncpu and available memory before you put that > in, right? If you have quad core and up, you could have 4 large ports > going at the same time as of Feb 2012. This is just a temporary dpb > issue while the rthreads/vmmap issues are being sorted out, right?
No, this is not a temporary issue. Look at the SIZES. If you are compiling the 4 biggest ports and they start linking at the same time, they WILL consume about 6GB of memory. And look at dpb's graphs. Postponing such ports slightly will have absolutely no impact on the total build time. Heck, less memory pressure and less cache pressure will probably make things faster.
