From: Peter Zijlstra <peterz@infradead.org>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Jesse Larrew <jlarrew@linux.vnet.ibm.com>
Subject: Re: [BUG] rebuild_sched_domains considered dangerous
Date: Thu, 10 Mar 2011 15:10:11 +0100 [thread overview]
Message-ID: <1299766211.2308.4468.camel@twins> (raw)
In-Reply-To: <1299675674.2308.2924.camel@twins>
On Wed, 2011-03-09 at 14:01 +0100, Peter Zijlstra wrote:
> On Wed, 2011-03-09 at 11:19 +0100, Peter Zijlstra wrote:
> > No, the domain stuff is good, we allocate new domains and have a
> > synchronize_sched() between us installing the new ones and freeing the
> > old ones.=20
>=20
> Gah, if only..
OK, so for hotplug and cpusets it works because they change the doms_cur
set, when the old and the new set don't match it destroys the current
sched_domain/sched_group sets for the relevant cpus and then calls
synchronize_sched() to wait for any current activity to go away.
Only then does it rebuild stuff for the new set, reusing the static
allocated sched_domain and sched_group data.
Now, supposedly when your new and old domain set is the same it should
be a nop, unless arch_update_cpu_topology() returns true in which case
it will do a full destroy and rebuild.
So I'm not quite sure what power does to make it go bang..
Anyway, I'm now rewriting the sched_domain creation stuff because I've
utterly had it with that code..
Also, still waiting to hear from the Power7 folks on how often they
think to rebuild the topology and how they think that makes sense,
afaict Power7 does have actual NUMA nodes unlike s390, so I'm still not
seeing how that's going to work properly at all.
next prev parent reply other threads:[~2011-03-10 14:10 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-09 2:58 [BUG] rebuild_sched_domains considered dangerous Benjamin Herrenschmidt
2011-03-09 10:19 ` Peter Zijlstra
2011-03-09 11:33 ` Peter Zijlstra
2011-03-09 13:15 ` Martin Schwidefsky
2011-03-09 13:19 ` Peter Zijlstra
2011-03-09 13:31 ` Martin Schwidefsky
2011-03-09 13:33 ` Peter Zijlstra
2011-03-09 13:46 ` Martin Schwidefsky
2011-03-09 13:54 ` Peter Zijlstra
2011-03-09 15:26 ` Steven Rostedt
2011-03-09 13:01 ` Peter Zijlstra
2011-03-10 14:10 ` Peter Zijlstra [this message]
2011-04-20 10:07 ` Peter Zijlstra
2011-04-20 22:01 ` Benjamin Herrenschmidt
2011-05-09 21:26 ` Jesse Larrew
2011-05-10 14:09 ` Peter Zijlstra
2011-05-11 16:17 ` Jesse Larrew
2011-06-03 14:47 ` Peter Zijlstra
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=1299766211.2308.4468.camel@twins \
--to=peterz@infradead.org \
--cc=benh@kernel.crashing.org \
--cc=jlarrew@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=schwidefsky@de.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).