1 |
On Sun, Nov 27, 2011 at 12:56 PM, Pandu Poluan <pandu@××××××.info> wrote: |
2 |
> On Nov 27, 2011 5:12 PM, "Michael Mol" <mikemol@×××××.com> wrote: |
3 |
|
4 |
[snip] |
5 |
|
6 |
> |
7 |
> Here's my experience: |
8 |
> |
9 |
> I always experience emerge failures on my Gentoo VMs if I use MAKEOPTS=-j>3. |
10 |
> Not all packages, but many. Including, IIRC, glibc and gcc. |
11 |
|
12 |
In my barebones 177-package state, I didn't get any build failures |
13 |
from parallel building, either via emerge -j or make -j. I did get one |
14 |
failure when I went to install X that worked fine on the second |
15 |
attempt. |
16 |
|
17 |
Parallel operations are finicky things; if you don't define the |
18 |
relationships correctly, you can have things work fine most of the |
19 |
time, and then a race condition between one make recipe and another |
20 |
(or perhaps between one ebuild and another; a revdep-rebuild afterward |
21 |
might not be a bad CYA) causes one thing to fail, just this one time. |
22 |
|
23 |
My day job is C++ on Windows[1], and we do a *lot* with multithreaded |
24 |
code. Race conditions are a PITA; you might not be able to reproduce a |
25 |
race-induced failure on any of the workstations or test systems you |
26 |
have, but then have it crop up consistently on a customer's system. |
27 |
The same principles can and will apply with things like parallel make |
28 |
and parallel emerge. I've even seen it happen in VS2005 and VS2008 |
29 |
parallel builds. |
30 |
|
31 |
> This happens even if I make sure that there's just one emerge job being |
32 |
> done. And this happens even if I allocate more vCPUs than -j, on VMware and |
33 |
> XenServer alike. |
34 |
|
35 |
FWIW, I've been running with MAKEOPTS=-j10 on my Phenom 9650 for over |
36 |
a year. It's very rare that something breaks due to the parallel |
37 |
build. I think it's happened perhaps three times, and each time was |
38 |
resolvable with a retry. YMMV, of course; race conditions are finicky. |
39 |
|
40 |
> I don't know where the 'blame' lies, but I've found myself standardizing on |
41 |
> MAKEOPTS=-j3, and PORTAGE_DEFAULT_OPTS="--jobs |
42 |
> --load-average=<1.6*num_of_vCPU>" |
43 |
> |
44 |
> (Yes, no explicit number of jobs. The newer portages are smart enough to |
45 |
> keep starting new jobs until the load number is reached) |
46 |
|
47 |
Sweet; I didn't know about Portage's --load-average; I'll definitely |
48 |
switch to that instead of -j. Load-driven make plus load-driven |
49 |
portage should work beautifully on my system. |
50 |
|
51 |
I'll steal your 1.6 factor, and give: |
52 |
MAKEOPTS=-j <2*N> -l <1.6*N) |
53 |
PORTAGE_DEFAULT_OPTS="--jobs --load-average<1.6*N>" |
54 |
a try. |
55 |
|
56 |
How does that interact with distcc, by the way? I've got two of these |
57 |
octo-core Xeon boxes, and I've still got my Phenom 9650--distcc on my |
58 |
home network should become very, very nice. And this box is consuming |
59 |
255W at the wall with monitor off, 326W with monitor on. That's not |
60 |
bad. Though perhaps I should move to an apartment where heat isn't |
61 |
free... |
62 |
|
63 |
[1] Well, for most of this year, my task list has been more |
64 |
PHP-oriented, but I'm still on tap for our C++ work. |
65 |
|
66 |
-- |
67 |
:wq |