linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>,
	mingo@kernel.org, pjt@google.com, paul@paulmenage.org,
	akpm@linux-foundation.org, rjw@sisk.pl, nacc@us.ibm.com,
	paulmck@linux.vnet.ibm.com, tglx@linutronix.de,
	seto.hidetoshi@jp.fujitsu.com, rob@landley.net, tj@kernel.org,
	mschmidt@redhat.com, berrange@redhat.com,
	nikunj@linux.vnet.ibm.com, vatsa@linux.vnet.ibm.com,
	linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-pm@vger.kernel.org
Subject: Re: [PATCH v2 0/7] CPU hotplug, cpusets: Fix issues with cpusets handling upon CPU hotplug
Date: Fri, 4 May 2012 14:27:58 -0700	[thread overview]
Message-ID: <20120504212758.GC3054@linux.vnet.ibm.com> (raw)
In-Reply-To: <1336165294.6509.76.camel@twins>

On 04.05.2012 [23:01:34 +0200], Peter Zijlstra wrote:
> On Fri, 2012-05-04 at 13:49 -0700, Nishanth Aravamudan wrote:
> > I think it's ok for hotplug to be destructive. But I guess I'm not
> > entirely sure why cpusets can't retain user-inputted
> > configuration/policy information even while destroying things currently?
> > And re-instating that policy if possible in the future? 
> 
> Two issues here:
>  - if you retain it for cpuset but not others that's confusing (too);

That's a good point.

Related, possibly counter-example, and perhaps I'm wrong about it.  When
we hot-unplug a CPU, and a task's scheduler affinity (via
sched_setaffinity) refers to that CPU only, do we kill that task? Can
you sched_setaffinity a task to a CPU that is offline (alone or in a
group of possible CPUs)? Or is it allowed to run anywhere? Do we destroy
its affinity policy when that situation is run across? Or do we restore
the task to the CPU again when we re-plug it? I'm just curious about
what the kernel does here and you probably know off the top of your head
:) It feels like a similar situation.

>  - we never retain anything, if you unload a module you loose all state
> that was associated with it too. What makes this special?

Another good point. I would think if we were talking about unmounting
cpusetfs altogether then what you say would correspond. But I feel like
there is some distinction between module unloading (and remembering
information about the module in question, I assume you mean things like
module parameters) and cpu hotplug (and remembering information about
cpuset configuration, which isn't necessarily directly related).

I don't have good answers to either of your points off the top of my
head -- but even if we say that "hey, userspace, you're dumb, get over
it", it feels like there could be more that we could do here. It seems
wrong to make every cpuset user (presuming there are more than just
libvirt & SGI) scan regularly for empty cpusets (I'm operating under the
assumption that the person setting up the cpuset configuration may not
be the same person that does the CPU hotplug operation).

Thanks,
Nish

-- 
Nishanth Aravamudan <nacc@us.ibm.com>
IBM Linux Technology Center


  reply	other threads:[~2012-05-04 21:29 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-04 19:17 [PATCH v2 0/7] CPU hotplug, cpusets: Fix issues with cpusets handling upon CPU hotplug Srivatsa S. Bhat
2012-05-04 19:17 ` [PATCH v2 1/7] cpusets, hotplug: Implement cpuset tree traversal in a helper function Srivatsa S. Bhat
2012-05-04 19:18 ` [PATCH v2 2/7] cpusets, hotplug: Restructure functions that are invoked during hotplug Srivatsa S. Bhat
2012-05-04 19:18 ` [PATCH v2 3/7] cpusets: Introduce 'user_cpus_allowed' and rework the semantics of 'cpus_allowed' Srivatsa S. Bhat
2012-05-04 19:19 ` [PATCH v2 4/7] CPU hotplug, cpusets: Workout hotplug handling for cpusets Srivatsa S. Bhat
2012-05-04 19:19 ` [PATCH v2 5/7] Docs, cpusets: Update the cpuset documentation Srivatsa S. Bhat
2012-05-04 22:28   ` Rob Landley
2012-05-04 19:20 ` [PATCH v2 6/7] cpusets: Optimize the implementation of guarantee_online_cpus() Srivatsa S. Bhat
2012-05-04 19:20 ` [PATCH v2 7/7] cpusets: Remove out-dated comment about cpuset_track_online_cpus Srivatsa S. Bhat
2012-05-04 19:24 ` [PATCH v2 0/7] CPU hotplug, cpusets: Fix issues with cpusets handling upon CPU hotplug Peter Zijlstra
2012-05-04 19:58   ` Srivatsa S. Bhat
2012-05-04 20:14     ` Peter Zijlstra
2012-05-04 20:28       ` Peter Zijlstra
2012-05-04 20:49         ` Nishanth Aravamudan
2012-05-04 21:01           ` Peter Zijlstra
2012-05-04 21:27             ` Nishanth Aravamudan [this message]
2012-05-04 21:32               ` Peter Zijlstra
2012-05-04 21:34               ` Peter Zijlstra
2012-05-04 21:57                 ` Nishanth Aravamudan
2012-05-04 21:38               ` Peter Zijlstra
2012-05-04 20:46       ` Nishanth Aravamudan
2012-05-04 20:56         ` Peter Zijlstra
2012-05-04 21:30           ` Nishanth Aravamudan
2012-05-04 21:44             ` Peter Zijlstra
2012-05-05 15:24               ` Alan Stern
2012-05-05 17:44                 ` Paul E. McKenney
2012-05-05 18:56                   ` Rafael J. Wysocki
2012-05-08 13:07             ` Daniel P. Berrange
2012-05-05  4:39           ` Mike Galbraith
2012-05-05 17:15         ` Srivatsa S. Bhat
2012-05-07 15:26           ` Jiang Liu
2012-05-09  9:12       ` Srivatsa S. Bhat

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=20120504212758.GC3054@linux.vnet.ibm.com \
    --to=nacc@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=berrange@redhat.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=mschmidt@redhat.com \
    --cc=nacc@us.ibm.com \
    --cc=nikunj@linux.vnet.ibm.com \
    --cc=paul@paulmenage.org \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=pjt@google.com \
    --cc=rjw@sisk.pl \
    --cc=rob@landley.net \
    --cc=seto.hidetoshi@jp.fujitsu.com \
    --cc=srivatsa.bhat@linux.vnet.ibm.com \
    --cc=tglx@linutronix.de \
    --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 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).