From: Thomas Gleixner <tglx@linutronix.de>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>,
Alan Stern <stern@rowland.harvard.edu>,
mingo@kernel.org, peterz@infradead.org,
paulmck@linux.vnet.ibm.com, namhyung@kernel.org, tj@kernel.org,
rjw@sisk.pl, nikunj@linux.vnet.ibm.com, linux-pm@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 0/6] CPU hotplug: Reverse invocation of notifiers during CPU hotplug
Date: Wed, 1 Aug 2012 09:10:09 +0200 (CEST) [thread overview]
Message-ID: <alpine.LFD.2.02.1208010907210.32033@ionos> (raw)
In-Reply-To: <87wr1pmz2q.fsf@rustcorp.com.au>
On Fri, 27 Jul 2012, Rusty Russell wrote:
> On Wed, 25 Jul 2012 18:30:41 +0200 (CEST), Thomas Gleixner <tglx@linutronix.de> wrote:
> > The problem with the current notifiers is, that we only have ordering
> > for a few specific callbacks, but we don't have the faintest idea in
> > which order all other random stuff is brought up and torn down.
> >
> > So I started experimenting with the following:
> >
> > struct hotplug_event {
> > int (*bring_up)(unsigned int cpu);
> > int (*tear_down)(unsigned int cpu);
> > };
> >
> > enum hotplug_events {
> > CPU_HOTPLUG_START,
> > CPU_HOTPLUG_CREATE_THREADS,
> > CPU_HOTPLUG_INIT_TIMERS,
> > ...
> > CPU_HOTPLUG_KICK_CPU,
> > ...
> > CPU_HOTPLUG_START_THREADS,
> > ...
> > CPU_HOTPLUG_SET_ONLINE,
> > ...
> > CPU_HOTPLUG_MAX_EVENTS,
> > };
>
> This looks awfully like hardcoded a list of calls, without the
> readability :)
I'd love to make it a list of calls, though we have module users of
cpu hotplug which makes a list of calls a tad hard.
> OK, I finally got off my ass and looked at the different users of cpu
> hotplug. Some are just doing crazy stuff, but most seem to fall into
> two types:
>
> 1) Hardware-style cpu callbacks (CPU_UP_PREPARE & CPU_DEAD)
> 2) Live cpu callbacks (CPU_ONLINE & CPU_DOWN_PREPARE)
>
> I think this is what Srivatsa was referring to with "physical" and
> "logical" parts. Maybe we should explicitly split them, with the idea
> that we'd automatically call the other one if we hit an error.
>
> struct cpu_hotplug_physical {
> int (*coming)(unsigned int cpu);
> void (*gone)(unsigned int cpu);
> };
>
> struct cpu_hotplug_logical {
> void (*arrived)(unsigned int cpu);
> int (*going)(unsigned int cpu);
> };
>
> Several of the live cpu callbacks seem racy to me, since we could be
> running userspace tasks before CPU_ONLINE. It'd be nice to fix this,
> too.
Yes, I know. I wan't to change that as well. The trick here is that we
can schedule per cpu stuff on a not fully online cpu and only when all
the callbacks have been executed allow user space tasks to be
scheduled on that newly online cpu.
Thanks,
tglx
prev parent reply other threads:[~2012-08-01 7:10 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-25 11:53 [RFC PATCH 0/6] CPU hotplug: Reverse invocation of notifiers during CPU hotplug Srivatsa S. Bhat
2012-07-25 11:53 ` [RFC PATCH 1/6] list, rcu: Introduce rcu version of reverse list traversal Srivatsa S. Bhat
2012-07-25 11:53 ` [RFC PATCH 2/6] notifiers: Convert notifier chain to circular doubly linked-list Srivatsa S. Bhat
2012-07-25 11:54 ` [RFC PATCH 3/6] notifiers: Add support for reverse invocation of notifier chains Srivatsa S. Bhat
2012-07-25 11:54 ` [RFC PATCH 4/6] sched, cpuset: Prepare scheduler and cpuset CPU hotplug callbacks for reverse invocation Srivatsa S. Bhat
2012-07-25 11:54 ` [RFC PATCH 5/6] sched, perf: Prepare migration and perf " Srivatsa S. Bhat
2012-07-25 11:55 ` [RFC PATCH 6/6] CPU hotplug: Invoke CPU offline notifiers in reverse order Srivatsa S. Bhat
2012-07-25 16:43 ` Tejun Heo
2012-07-25 14:57 ` [RFC PATCH 0/6] CPU hotplug: Reverse invocation of notifiers during CPU hotplug Alan Stern
2012-07-25 15:56 ` Srivatsa S. Bhat
2012-07-25 16:10 ` Alan Stern
2012-07-25 16:37 ` Srivatsa S. Bhat
2012-07-25 16:43 ` Paul E. McKenney
2012-07-25 19:44 ` Alan Stern
2012-07-25 16:30 ` Thomas Gleixner
2012-07-25 16:51 ` Srivatsa S. Bhat
2012-07-26 11:02 ` Thomas Gleixner
2012-07-26 11:11 ` Srivatsa S. Bhat
2012-07-25 18:22 ` Srivatsa S. Bhat
2012-07-26 10:55 ` Thomas Gleixner
2012-07-26 11:13 ` Srivatsa S. Bhat
2012-07-26 11:22 ` Srivatsa S. Bhat
2012-07-27 7:40 ` Rusty Russell
2012-08-01 7:10 ` Thomas Gleixner [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=alpine.LFD.2.02.1208010907210.32033@ionos \
--to=tglx@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=namhyung@kernel.org \
--cc=nikunj@linux.vnet.ibm.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=rjw@sisk.pl \
--cc=rusty@rustcorp.com.au \
--cc=srivatsa.bhat@linux.vnet.ibm.com \
--cc=stern@rowland.harvard.edu \
--cc=tj@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox