On Nov 27, 2011 5:12 PM, "Michael Mol" <mike...@gmail.com> wrote: > > I figure that the optimal number of simultaneous CPU-consuming > processes is going to be the number of CPU cores, plus enough to keep > the CPU occupied while others are blocked on I/O. That's the same > reasoning that drives the selection of a -j number, really. > > If I read make's man page correctly, -l acts as a threshold, choosing > not to spawn an additional child process if the system load average is > above a certain value Since system load is a count of actively running > and ready-to-run processes, you want it to be very close to your > number of logical cores[1]. > > Since it's going to be a spot decision for Make as to whether or not > to spawn another child (if it hits its limit, it's not going to check > again until after one of its children returns), there will be many > race cases where the load average is high when it looks, but some > other processes will return shortly afterward.[2] That means adding a > process or two for a fudge factor. > > That's a lot of guess, though, and it still comes down to guess-and-check. > > emerge -j8 @world # MAKEOPTS="-j16 -l10" > > Was the first combination I tried. This completed in 89 minutes. > > emerge -j8 @world # MAKEOPT="-j16 -l8" > > Was the second. This took significantly longer. > > I haven't tried higher than -l10; I needed this box to do be able to > do things, which meant installing more software. I've gone from 177 > packages to 466. > > [1] I don't have a hyperthreading system available, but I suspect that > this is also going to be true of logical cores; It's my understanding > that the overhead from overcommitting CPU comes primarily from context > switching between processors, and hyperthreading adds CPU hardware > specifically to reduce the need to context-switch in splitting > physical CPU resources between threads/processes. So while you'd lose > a little speed for an individual thread, you would gain it back in > aggregate over both threads. > > [2] There would also be cases where the load average is low, such as > if a Make recipe calls for a significant bit of I/O before it consumes > a great deal of CPU, but a simple 7200rpm SATA disk appears to be > sufficiently fast that this case is less frequent.
Here's my experience: I always experience emerge failures on my Gentoo VMs if I use MAKEOPTS=-j>3. Not all packages, but many. Including, IIRC, glibc and gcc. This happens even if I make sure that there's just one emerge job being done. And this happens even if I allocate more vCPUs than -j, on VMware and XenServer alike. I don't know where the 'blame' lies, but I've found myself standardizing on MAKEOPTS=-j3, and PORTAGE_DEFAULT_OPTS="--jobs --load-average=<1.6*num_of_vCPU>" (Yes, no explicit number of jobs. The newer portages are smart enough to keep starting new jobs until the load number is reached) Rgds,
