public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

      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