From: Max Krasnyansky <maxk@qualcomm.com>
To: Paul Jackson <pj@sgi.com>
Cc: heiko.carstens@de.ibm.com, oleg@tv-sign.ru,
akpm@linux-foundation.org, ego@in.ibm.com, menage@google.com,
peterz@infradead.org, vegard.nossum@gmail.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] S390 topology: don't use kthread() for arch_reinit_sched_domains()
Date: Mon, 30 Jun 2008 12:49:21 -0700 [thread overview]
Message-ID: <486938C1.90907@qualcomm.com> (raw)
In-Reply-To: <20080630143334.66033f60.pj@sgi.com>
Paul Jackson wrote:
> Max wrote:
>> we either have to ... or change arch_init_sched_domains() to no destroy
>> current domains.
>
> I might be misreading this, but I doubt that just not destroying
> current domains is an option. Once any CPU goes on or off line, the
> only way back to the new correct sched domain configuration is via the
> rebuild_sched_domains() routine in kernel/cpuset.c.
>
Despite all the typos and missing words you read it correctly :). Here
is what I'm thinking.
When a CPU goes off line overall partitioning does not change we just
need to update current domains and remove the CPU that is no longer
available. When a CPU goes online it always ends up in the root cpuset,
which means it can be added to the first load-balanced sched domain.
In other words I'm thinking of simulating what rebuild_sched_domains()
would've done on hotplug events and calling partition_sched_domains()
directly from sched cpu hotplug code.
That way we can avoid cpuset/cgroup locking in that path.
Now, I haven't really looked into details. Maybe it's not feasible. In
which case Paul M.'s new locking scheme is the way to go.
Max
next prev parent reply other threads:[~2008-06-30 19:49 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-29 16:51 [PATCH 2/2] S390 topology: don't use kthread() for arch_reinit_sched_domains() Oleg Nesterov
2008-06-30 13:45 ` Heiko Carstens
2008-06-30 19:01 ` Max Krasnyansky
2008-06-30 19:33 ` Paul Jackson
2008-06-30 19:49 ` Max Krasnyansky [this message]
2008-06-30 20:28 ` Paul Jackson
2008-06-30 20:47 ` Max Krasnyansky
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=486938C1.90907@qualcomm.com \
--to=maxk@qualcomm.com \
--cc=akpm@linux-foundation.org \
--cc=ego@in.ibm.com \
--cc=heiko.carstens@de.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=menage@google.com \
--cc=oleg@tv-sign.ru \
--cc=peterz@infradead.org \
--cc=pj@sgi.com \
--cc=vegard.nossum@gmail.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.