From: Ingo Molnar <mingo@elte.hu>
To: Peter Zijlstra <peterz@infradead.org>
Cc: lookeylam <lookeylam@gmail.com>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: About CPU's Load Balance and CFS functions
Date: Tue, 8 Sep 2009 08:55:19 +0200 [thread overview]
Message-ID: <20090908065519.GC6505@elte.hu> (raw)
In-Reply-To: <1252351192.7503.29.camel@twins>
* Peter Zijlstra <peterz@infradead.org> wrote:
> On Mon, 2009-09-07 at 16:14 +0800, lookeylam wrote:
> > Hello:
> > I am not sure this is the right maillist to ask this
> > question. I just have a try.
> > I have a test on Dell 1950 with 8 cpus on board for testing
> > the apache by ab command. And I find that in
> > linux 2.6.18. The processes forked by apache are not well
> > distributed on these 8 cpus.
> > linux 2.6.23 is a little better than 2.6.18, but still some
> > cpus are running busy and some cpus remains idle.
> > While in 2.6.30, these 8 cpus are well used and the
> > percentage of each cpu is nearly the same. And when I
> > start the control group with cpuset type with
> > sched_relax_domain_level( with value 3,4,5). The result of ab is 50ms
> > better than test results without control group.
> >
> > I attribute this situation to to load_balance but not CFS,
> > because CFS is just a scheduler for orgnizing the process inside one
> > cpu, while load_balance is the main character to control the process
> > and load between different cpus.
> > But when i give out this conclusion, I confuse about the
> > differences of these three kernels of load_balance.
> >
> > My questions are the above conclusion is right or not? How
> > would these situation happen and why? I read the code of the kernel
> > but I am still not sure.
>
> load-balancing is generally considered part of the scheduler as a
> whole, while CFS is indeed the cpu scheduler, it and the
> load-balancer are related because they do have to work together.
>
> Now, in the past 3+years the load-balancer has undergone
> significant changes too -- and we're now again poking at it, .32
> will likely have quite radical changes to the whole load balancer.
>
> The sched_relax_domain_level knob is one that controls one of the
> coupling mechanisms, namely wake on idle, that is, we try and push
> newly woken tasks away to idle cpus. The level you put in there is
> related to the sched_domain level.
>
> Normally we don't try and push newly woken tasks too far away,
> because that'll increase the remote access penalty for related
> tasks, but some workloads have lots of very short running
> unrelated tasks which do benefit from this.
>
> Anyway, I would suggest you keep an eye out for scheduler patches
> if you're interested in this, all the scheduler development
> happens in -tip.
Which can be tested via:
http://people.redhat.com/mingo/tip.git/README
Ingo
prev parent reply other threads:[~2009-09-08 6:55 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-07 8:14 About CPU's Load Balance and CFS functions lookeylam
2009-09-07 19:19 ` Peter Zijlstra
2009-09-08 6:55 ` Ingo Molnar [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=20090908065519.GC6505@elte.hu \
--to=mingo@elte.hu \
--cc=linux-kernel@vger.kernel.org \
--cc=lookeylam@gmail.com \
--cc=peterz@infradead.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.