All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
	"Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>,
	Arjan van de Ven <arjan@infradead.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	"Rafael J. Wysocki" <rjw@sisk.pl>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	Paul Gortmaker <paul.gortmaker@windriver.com>,
	Milton Miller <miltonm@bga.com>, "mingo@elte.hu" <mingo@elte.hu>,
	Tejun Heo <tj@kernel.org>,
	KOSAKI Motohiro <kosaki.motohiro@gmail.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Linux PM mailing list <linux-pm@vger.kernel.org>
Subject: Re: CPU Hotplug rework
Date: Thu, 22 Mar 2012 15:49:20 -0700	[thread overview]
Message-ID: <20120322224919.GW2450@linux.vnet.ibm.com> (raw)
In-Reply-To: <87d3859s9r.fsf@rustcorp.com.au>

On Thu, Mar 22, 2012 at 02:55:04PM +1030, Rusty Russell wrote:
> On Wed, 21 Mar 2012 10:01:59 +0100, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> > On Wed, 2012-03-21 at 09:30 +1030, Rusty Russell wrote:
> > > > > (2) Do something more efficient with userspace threads than migrating
> > > > >     them one at a time.
> > > > 
> > > > Sadly that can't really be done. We need to pick up every task
> > > > (userspace, but also running kernel threads) and update their state.
> > > 
> > > What if we had an "orphan" runqueue which everyone pulled from?  Then we
> > > could grab the lock, move them all to the fake rq, then let stuff happen
> > > normally.
> > 
> > Well, we could simply let them sit where they are and fudge load-balance
> > to consider it a source but not a destination until its empty, but it
> > might be somewhat tricky to make it fast enough to not introduce
> > noticable latencies. Also, you really don't want everyone to pull,
> > that's a serialization/scalability problem.
> > 
> > Also, since we really only move the currently runnable tasks it
> > shouldn't be too many in the first place. Is it really that expensive?
> 
> Good question, requires measurement to answer.
> 
> > > Maybe that's crap, but at least we could move the migration out of the
> > > hotplug callback somehow. 
> > 
> > Thing is, if its really too much for some people, they can orchestrate
> > it such that its not. Just move everybody in a cpuset, clear the to be
> > offlined cpu from the cpuset's mask -- this will migrate everybody away.
> > Then hotplug will find an empty runqueue and its fast, no?
> 
> I like this solution better.

As long as we have some way to handle kthreads that are algorithmically
tied to a given CPU.  There are coding conventions to handle this, for
example, do everything with preemption disabled and just after each
preempt_disable() verify that you are in fact running on the correct
CPU, but it is easy to imagine improvements.

							Thanx, Paul


  reply	other threads:[~2012-03-22 22:49 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-19 14:44 CPU Hotplug rework Srivatsa S. Bhat
2012-03-19 14:48 ` Srivatsa S. Bhat
2012-03-20 11:28   ` Peter Zijlstra
2012-04-05 17:39   ` Paul E. McKenney
2012-04-05 17:55     ` Paul E. McKenney
2012-04-05 23:06       ` Paul E. McKenney
2012-04-06 20:15         ` Srivatsa S. Bhat
2012-04-09 16:46           ` Paul E. McKenney
2012-04-10  7:56             ` Nikunj A Dadhania
2012-04-06 19:52     ` Srivatsa S. Bhat
2012-04-09 17:13       ` Paul E. McKenney
2012-04-10 13:41         ` Srivatsa S. Bhat
2012-04-10 15:46           ` Paul E. McKenney
2012-04-10 17:26             ` Srivatsa S. Bhat
2012-04-11  0:09       ` Steven Rostedt
2012-04-11  0:28         ` Paul E. McKenney
2012-04-11  0:37           ` Steven Rostedt
2012-04-11  1:00             ` Paul E. McKenney
2012-04-11  6:02               ` Srivatsa S. Bhat
2012-04-11 12:28                 ` Paul E. McKenney
2012-03-19 23:42 ` Rusty Russell
2012-03-20 10:42   ` Peter Zijlstra
2012-03-20 23:00     ` Rusty Russell
2012-03-21  9:01       ` Peter Zijlstra
2012-03-22  4:25         ` Rusty Russell
2012-03-22 22:49           ` Paul E. McKenney [this message]
2012-03-23 23:27             ` Rusty Russell
2012-03-24  0:23               ` Paul E. McKenney
2012-03-26  0:41                 ` Rusty Russell
2012-03-26  8:02                   ` Peter Zijlstra
2012-03-26 13:09                     ` Steven Rostedt
2012-03-26 13:38                       ` Peter Zijlstra
2012-03-26 15:22                         ` Steven Rostedt
2012-03-26 16:13                           ` Peter Zijlstra
2012-03-26 17:05                             ` Steven Rostedt
2012-03-26 17:59                               ` Peter Zijlstra
2012-03-27  1:32                               ` Rusty Russell
2012-03-27  3:05                                 ` Steven Rostedt

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=20120322224919.GW2450@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=arjan@infradead.org \
    --cc=kosaki.motohiro@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=miltonm@bga.com \
    --cc=mingo@elte.hu \
    --cc=paul.gortmaker@windriver.com \
    --cc=rjw@sisk.pl \
    --cc=rostedt@goodmis.org \
    --cc=rusty@rustcorp.com.au \
    --cc=srivatsa.bhat@linux.vnet.ibm.com \
    --cc=tj@kernel.org \
    --cc=vatsa@linux.vnet.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 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.