Re: Dual Athlon MP 1900+ on MSI K7D Master-L

Kelledin (kelledin+LKML@skarpsey.dyndns.org)
Thu, 18 Jul 2002 21:14:30 -0500


On Thursday 18 July 2002 08:31 pm, Dieter Nützel wrote:
> Alan, were should I put the "-j2/-j3" make flag for the kernel
> compilation? /usr/src/linux/Documentation/smp.txt is way
> outdated ;-(
>
> Is there a place (maybe in /usr/lib/rpmrc; SuSE/RedHat) to get
> both CPUs running during RPM packages compilation?

Alan may have a different answer for you, but in my experience,
you can just specify the -j<whatever> flag when you run make
(and also set the MAKE variable to "make -j<whatever>". The
speed benefit really kicks in when making bzImage or modules.

In general, I find it best to set the number of jobs to the
number of CPUs _plus 1_--i.e. for single CPU, use make -j2, and
for dual CPUs, use make -j3. Going for that "plus 1" makes most
builds just a smidgen faster. For me, on my dual PPro box, the
process would be something like:

make menuconfig
make -j3 MAKE="make -j3" dep clean bzImage modules

Doing just a bare "make -j" (using just "-j" where you'd normally
use "-j<whatever>") is never good, even if you actually do have
tons and tons of mem+swap. Besides sucking up memory like
there's no tomorrow, it hammers the system with context switches
and forces the build to spend way too much of its time stuck in
the process scheduler. This makes a nice brutal stress-test for
a system, but it slows your build to a crawl.

AFAIK, the only way to get RPM packages to use "make
-j<whatever>" is to edit their spec files manually, have the
%build scriptlet look in /proc/cpuinfo to discover the number of
CPUs, and then have the scriptlet explicitly call make with
appropriate -j parameters. You might want to do this both in
the %build and %install scriptlets, since environment variable
settings in the %build scriptlet don't necessarily carry over
into %install.

Beware, also, that many build scripts will not work properly with
"make -j<whatever>". A parallel build as a whole may work, or
it may not. Some source packages may fail loudly and die. A
few may appear to complete successfully, yet silently fail to
install some file or another. It's fairly common for source
trees not to be 100% "parallel-build safe", and the kernel is no
exception.

You could possibly complain to developers about this, but most
developers have higher priorities than catering to people with
multiple CPUs. ;) So using "make -j<whatever>" should always be
considered "experimental."

--
Kelledin
"If a server crashes in a server farm and no one pings it, does 
it still cost four figures to fix?"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/