When building chromium in parallel (e.g. MAKEOPTS="-jN" with N>1), it just blindly forks build-processes, irrespective of the current system load. I patched the current stable ebuild on my system to take advantage of an enhancement I submitted in https://bugs.gentoo.org/show_bug.cgi?id=490620 . Reproducible: Always
Created attachment 362708 [details] chromium-30.0.1599.101-r1.ebuild please note: this ebuild only works in conjunction with the eclass from bug 490620.
$ diff -Naur /usr/portage/www-client/chromium/chromium-30.0.1599.101.ebuild chromium-30.0.1599.101-r1.ebuild --- /usr/portage/www-client/chromium/chromium-30.0.1599.101.ebuild 2013-10-16 15:01:36.000000000 +0200 +++ chromium-30.0.1599.101-r1.ebuild 2013-11-06 23:14:46.253242314 +0100 @@ -379,7 +379,11 @@ # Even though ninja autodetects number of CPUs, we respect # user's options, for debugging with -j 1 or any other reason. - ninja -C out/Release -v -j $(makeopts_jobs) ${ninja_targets} || die + ninja -C out/Release \ + -v \ + -j $(makeopts_jobs) \ + -l $(makeopts_loadavg) \ + ${ninja_targets} || die pax-mark m out/Release/chrome if use test; then
(In reply to M. B. from comment #2) > $ diff -Naur /usr/portage/www-client/chromium/chromium-30.0.1599.101.ebuild > chromium-30.0.1599.101-r1.ebuild > --- /usr/portage/www-client/chromium/chromium-30.0.1599.101.ebuild > 2013-10-16 15:01:36.000000000 +0200 > +++ chromium-30.0.1599.101-r1.ebuild 2013-11-06 23:14:46.253242314 +0100 > @@ -379,7 +379,11 @@ > > # Even though ninja autodetects number of CPUs, we respect > # user's options, for debugging with -j 1 or any other reason. > - ninja -C out/Release -v -j $(makeopts_jobs) ${ninja_targets} || die > + ninja -C out/Release \ > + -v \ > + -j $(makeopts_jobs) \ > + -l $(makeopts_loadavg) \ > + ${ninja_targets} || die > > pax-mark m out/Release/chrome > if use test; then Thank you for your contribution. It's generally good, but I'd like to see one issue addressed before this can get accepted: without -l in the MAKEOPTS, I think this will result in passing -l 1 to ninja. This is different from the previous behavior, which would not add any loadavg limits. Could you modify the patch so that -l is only passed to ninja when -l is actually set in the MAKEOPTS? Note that while it's reasonable to assume -j 1 if it's not present in MAKEOPTS, I don't think the same reasoning would apply to -l (which is much less common flag and most people don't have it set).
(In reply to Paweł Hajdan, Jr. from comment #3) I went ahead and committed a solution to the latest ebuild. If you think it looks ok, I will copy it to the beta and stable channel ebuilds. + 08 Dec 2013; Mike Gilbert <floppym@gentoo.org> chromium-33.0.1726.0.ebuild: + Refactor ninja option processing into eninja function. Add load average + support, thanks to M.B. in bug 490624.
(In reply to Mike Gilbert from comment #4) > I went ahead and committed a solution to the latest ebuild. If you think it > looks ok, I will copy it to the beta and stable channel ebuilds. Sounds good, code looks OK. Thanks. I'd slightly prefer not to modify stable ebuilds, even with seemingly safe changes (unless they fix really serious bugs affecting large part of our user base). Up to you.
(In reply to Mike Gilbert from comment #4) > (In reply to Paweł Hajdan, Jr. from comment #3) > > I went ahead and committed a solution to the latest ebuild. If you think it > looks ok, I will copy it to the beta and stable channel ebuilds. > > + 08 Dec 2013; Mike Gilbert <floppym@gentoo.org> > chromium-33.0.1726.0.ebuild: > + Refactor ninja option processing into eninja function. Add load average > + support, thanks to M.B. in bug 490624. Since chromium-34 is now stable I'm closing this as fixed.
