From: Max Krasnyansky <maxk@qualcomm.com>
To: Dimitri Sivanich <sivanich@sgi.com>
Cc: Li Zefan <lizf@cn.fujitsu.com>,
Gregory Haskins <ghaskins@novell.com>,
Derek Fults <dfults@sgi.com>,
Peter Zijlstra <peterz@infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@elte.hu>
Subject: Re: RT sched: cpupri_vec lock contention with def_root_domain and no load balance
Date: Mon, 24 Nov 2008 13:47:15 -0800 [thread overview]
Message-ID: <492B20E3.5000900@qualcomm.com> (raw)
In-Reply-To: <20081124151113.GB2292@sgi.com>
Dimitri Sivanich wrote:
> On Sat, Nov 22, 2008 at 04:18:29PM +0800, Li Zefan wrote:
>> Max Krasnyansky wrote:
>>> Dimitri Sivanich wrote:
>>>> Which is the way sched_load_balance is supposed to work. You need to set
>>>> sched_load_balance=0 for all cpusets containing any cpu you want to disable
>>>> balancing on, otherwise some balancing will happen.
>>> It won't be much of a balancing in this case because this just one cpu per
>>> domain.
>>> In other words no that's not how it supposed to work. There is code in
>>> cpu_attach_domain() that is supposed to remove redundant levels
>>> (sd_degenerate() stuff). There is an explicit check in there for numcpus == 1.
>>> btw The reason you got a different result that I did is because you have a
>>> NUMA box where is mine is UMA. I was able to reproduce the problem though by
>>> enabling multi-core scheduler. In which case I also get one redundant domain
>>> level CPU, with a single CPU in it.
>>> So we definitely need to fix this. I'll try to poke around tomorrow and figure
>>> out why redundant level is not dropped.
>>>
>> You were not using latest kernel, were you?
>>
>> There was a bug in sd degenerate code, and it has already been fixed:
>> http://lkml.org/lkml/2008/11/8/10
>
> With the above patch added, we now see the results that Max is
> showing as far as individual root domains being created with a span
> of just their own cpu when sched_load_balance is turned off.
Nice.
Max
next prev parent reply other threads:[~2008-11-24 21:47 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-03 21:07 RT sched: cpupri_vec lock contention with def_root_domain and no load balance Dimitri Sivanich
2008-11-03 22:33 ` Peter Zijlstra
2008-11-04 1:29 ` Dimitri Sivanich
2008-11-04 3:53 ` Gregory Haskins
2008-11-04 14:34 ` Gregory Haskins
2008-11-04 14:36 ` Peter Zijlstra
2008-11-04 14:40 ` Dimitri Sivanich
2008-11-04 14:59 ` Gregory Haskins
2008-11-19 19:49 ` Max Krasnyansky
2008-11-19 19:55 ` Dimitri Sivanich
2008-11-19 20:17 ` Max Krasnyansky
2008-11-19 20:21 ` Dimitri Sivanich
2008-11-19 20:25 ` Gregory Haskins
2008-11-19 20:33 ` Dimitri Sivanich
2008-11-19 21:30 ` Gregory Haskins
2008-11-19 21:47 ` Dimitri Sivanich
2008-11-19 22:25 ` Gregory Haskins
2008-11-20 2:12 ` Max Krasnyansky
2008-11-21 1:57 ` Gregory Haskins
2008-11-21 20:04 ` Max Krasnyansky
2008-11-21 21:18 ` Dimitri Sivanich
2008-11-22 7:03 ` Max Krasnyansky
2008-11-22 8:18 ` Li Zefan
2008-11-24 15:11 ` Dimitri Sivanich
2008-11-24 21:47 ` Max Krasnyansky [this message]
2008-11-24 21:46 ` Max Krasnyansky
2008-11-04 14:45 ` Dimitri Sivanich
2008-11-06 9:13 ` Nish Aravamudan
2008-11-06 13:32 ` Dimitri Sivanich
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=492B20E3.5000900@qualcomm.com \
--to=maxk@qualcomm.com \
--cc=dfults@sgi.com \
--cc=ghaskins@novell.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lizf@cn.fujitsu.com \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=sivanich@sgi.com \
/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.