suggest 'make -j2' for SMP machines?

Bryan Kadzban bryan at kadzban.is-a-geek.net
Tue Jun 5 04:13:51 PDT 2007


Greg Schafer wrote:
> A lot of seasoned SMP-building folks work on the basis of make -j X+1
> ie: make -j3 if you have 2 cpus or 2 cores. As a person who has been
> building in parallel for a long time, I strongly disagree with a
> comment elsewhere in this thread about performance plummeting if
> overutilizing.

(Note this is all theoretical: I haven't really tested it.  I've built a
few packages with -j2 on my dual-core machine, but I never looked into
the optimal -j setting much.  So if you use X+1 and it works well, that
probably trumps my guesses.)

If you have one CPU, and make runs two jobs, *and* both jobs are
CPU-bound, then performance will probably only be slightly worse than
running one job.  The overhead of switching between the two tasks will
take some time, but not very much.

If you have two CPUs, and make runs three CPU-bound jobs, then they'll
still finish much faster than they'd take with -j1.  But since only two
can run at a time, the third will fight with them for CPU; it *may* be
faster to only run two, and make the third one wait.  Then you won't
have to context-switch as much (although the kernel still might try).
But I don't know this for sure.

And here's my guess for why X+1 works well: most compiles don't seem to
be entirely CPU-bound.  When compiling packages, I can see my (per-core)
CPU usage, and it's not usually 100%.  I suspect the cost of going after
the disk to load the source files in and write the object files out (not
to mention the temp files if you don't use -pipe) is much greater than
the cost of parsing and optimizing a small C file.  And lots of packages
(maybe most?) seem to be made up of many small C files.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfromscratch.org/pipermail/lfs-dev/attachments/20070605/fd389ca1/attachment.sig>


More information about the lfs-dev mailing list