From: Peter Williams <pwil3058@bigpond.net.au>
To: Jesper Juhl <jesper.juhl@gmail.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Sam Ravnborg <sam@ravnborg.org>, Andrew Morton <akpm@osdl.org>,
Paul Fulghum <paulkf@microgate.com>,
"linux-os (Dick Johnson)" <linux-os@analogic.com>,
Jan Engelhardt <jengelh@linux01.gwdg.de>,
Ingo Molnar <mingo@elte.hu>, Robert Love <rml@tech9.net>
Subject: Re: Odd sched behaviour; It takes 5 threads or more to load 2 CPU cores during kernel build
Date: Wed, 01 Mar 2006 10:27:15 +1100 [thread overview]
Message-ID: <4404DC53.1040409@bigpond.net.au> (raw)
In-Reply-To: <9a8748490602281159u58df3397g1b6b268787146448@mail.gmail.com>
Jesper Juhl wrote:
> Hi everyone,
>
> This is a continuation of the issue I initially reported in the "make
> -j with j <= 4 seems to only load a single CPU core" thread
> (http://lkml.org/lkml/2006/2/21/231).
>
> I've now got some more data, so hopefully someone can help me get a
> handle on this thing.
>
> In a nutshell the problem is that I need to run "make -j N" where N is
>
>>= 5 in order to put maximum load on both cores of my Athlon 64 X2
>
> 4400+ when building kernels and with N < 5 the build apears to be
> pretty much done serially and not at all parallel. This baffles me to
> be honest.
> The expected behaviour is that running with "make -j 2" on an
> otherwise idle machine would schedule a CC to run on each core most of
> the time, and with "make -j 3" & "make -j 4" there should definately
> be something executing on both cores all the time.
> What I see is that unless I bump it up to -j 5 or greater only one
> core seems to be put to work and the other one mostly just sits around
> spinning its wheels doing nothing.
Out of concern that this problem may be caused by the smpnice patches
(which modify load balancing) I've done some testing on my HT
workstation (with 2.6.16-rc4 installed). The short summary of the
results of my tests is that the smpnice patches do not appear to be at
fault and that the problem lies in the kernel build mechanism for recent
kernels.
More detail:
Test 1: build linux-2.6.14 with "make -j 2" and observe the results
using top with the "latest CPU ran on" column enabled. Result: both
channels are being used and the build appears to be running in parallel.
Test 2: do the same test with a 2.6.16-rc5 kernel source. Result: both
channels are not being used and the build appears to be running serially.
Hence my conclusion that the problem is caused by recent (since 2.6.14)
changes to the build mechanism and that it is not a scheduler or load
balancing problem.
The good news from this is that a binary search trying to find when the
problem doesn't need to reboot with the kernels each time but just
evaluate the build process.
Peter
--
Peter Williams pwil3058@bigpond.net.au
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
prev parent reply other threads:[~2006-02-28 23:27 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-28 19:59 Odd sched behaviour; It takes 5 threads or more to load 2 CPU cores during kernel build Jesper Juhl
2006-02-28 20:21 ` Christian
2006-02-28 20:48 ` Jesper Juhl
2006-02-28 23:27 ` Peter Williams [this message]
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=4404DC53.1040409@bigpond.net.au \
--to=pwil3058@bigpond.net.au \
--cc=akpm@osdl.org \
--cc=jengelh@linux01.gwdg.de \
--cc=jesper.juhl@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-os@analogic.com \
--cc=mingo@elte.hu \
--cc=paulkf@microgate.com \
--cc=rml@tech9.net \
--cc=sam@ravnborg.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.