On Mon, Nov 28, 2011 at 16:27, Neil Bothwick <n...@digimed.co.uk> wrote: > On Sun, 27 Nov 2011 23:34:14 -0500, Michael Mol wrote: > >> >> The problem I found with that is the ebuilds load the system lightly >> >> to start with, before they enter the compile phase, to portage >> >> starts dozens of parallel ebuilds, then the system gets completely >> >> bogged down when they start compiling. > >> > Yes, sometimes that would happen if at the beginning there are >> > network-bound ebuilds all downloading their respective distfiles. The >> > load stays low until they all start ./configure-ing roughly at the >> > same time. Then all hell breaks loose. >> > >> > I successfully mitigate such "load-explosion" by doing a --fetchonly >> > step first, and keeping MAKEOPTS at low -j (which, in my case, is >> > actually required). > > It doesn't help here, as my cron script that runs emerge --sync already > follows it with emerge -f @world. > >> As I noted, "-l" in MAKEOPTS takes care of the load explosion very >> nicely. > > From the description, it should do just that, there may still be dozens > of ebuilds in progress, but only the first few will actually start > compiling. Adding it now. It should also helps when there are multiple > emerge processes running, my desktop acts as a build host for lower > powered systems too. Adding -l10 now. >
Just tried adding "-l7.2" to MAKEOPTS ... ... and indeed, emerge -1avuND --changed-use @system @world seems faster than without. What's for sure, the emerge's output shows higher parallelism than without. Hmmm... gotta try it with emerge -e @system @world sometime :-) Rgds, -- FdS Pandu E Poluan ~ IT Optimizer ~ • LOPSA Member #15248 • Blog : http://pepoluan.tumblr.com • Linked-In : http://id.linkedin.com/in/pepoluan
