public inbox for gentoo-project@lists.gentoo.org
 help / color / mirror / Atom feed
From: Ulrich Mueller <ulm@gentoo.org>
To: gentoo-project@lists.gentoo.org
Subject: Re: [gentoo-project] EAPI6 Features
Date: Sun, 8 Jun 2014 18:56:23 +0200	[thread overview]
Message-ID: <21396.38327.477146.382158@a1i15.kph.uni-mainz.de> (raw)
In-Reply-To: <20140608172923.1d5557d8@marga.jer-c2.orkz.net>

[-- Attachment #1: Type: text/plain, Size: 1198 bytes --]

>>>>> On Sun, 8 Jun 2014, Jeroen Roovers wrote:

> On Sun, 8 Jun 2014 09:04:20 -0400
> Rich Freeman <rich0@gentoo.org> wrote:

>> >    c) EJOBS variable
>> >         Bug #273101 [17], gentoo-dev discussion [18]
>> >         - Discussion was in 2008. Is there (still) consensus?

>> The only thing that might be worth noting is that distcc users may
>> have an interest in distinguishing between gcc jobs and everything
>> else.  I once messed with dictcc with very high job numbers and it
>> worked great when make hit a directory full of .c files, and not so
>> great when make/ant/whatever tried to run 50 instances of java in
>> parallel.

> Not just distcc! We already regularly see problems with a
> combination of (a) tons of RAM, (b) a dozen CPUs and (b) matching
> MAKEOPTS and (d) -pipe, where concurrent linker jobs surprisingly
> consume all of the RAM and one or more linker jobs segfault or get
> killed. Anyone's MAKEOPTS calculation should already include all of
> those factors.

Also, extraction of jobs and load average from MAKEOPTS isn't so
complicated. In fact, multiprocessing.eclass already provides
functions makeopts_jobs() and makeopts_loadavg() for this purpose.

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

  reply	other threads:[~2014-06-08 16:56 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-08 13:04 [gentoo-project] EAPI6 Features Rich Freeman
2014-06-08 14:38 ` Ulrich Mueller
2014-06-08 15:09   ` Rich Freeman
2014-06-08 19:15   ` Pacho Ramos
2014-06-08 20:56     ` Ulrich Mueller
2014-06-09  8:50       ` Pacho Ramos
2014-06-08 21:49   ` Michał Górny
2014-06-08 15:29 ` Jeroen Roovers
2014-06-08 16:56   ` Ulrich Mueller [this message]
2014-06-08 17:22 ` Andreas K. Huettel
2014-06-08 17:26   ` Ciaran McCreesh
2014-06-08 17:28   ` Ulrich Mueller
2014-06-08 21:40     ` Michał Górny
2014-06-08 22:58       ` Rich Freeman
2014-06-09  2:57         ` Michał Górny
2014-06-09 10:12           ` Ulrich Mueller
2014-06-09 14:31 ` Ian Stakenvicius
2014-06-09 15:29   ` [gentoo-project] " Jonathan Callen
2014-06-09 16:23     ` Ulrich Mueller
2014-06-09 16:31       ` Michał Górny
2014-06-09 16:43         ` Ian Stakenvicius
2014-06-09 16:47         ` Ulrich Mueller
2014-06-09 19:20         ` Jeroen Roovers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=21396.38327.477146.382158@a1i15.kph.uni-mainz.de \
    --to=ulm@gentoo.org \
    --cc=gentoo-project@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox