From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
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, 04 May 2012 23:44:12 +0200 [thread overview]
Message-ID: <1336167852.6509.90.camel@twins> (raw)
In-Reply-To: <20120504213010.GD3054@linux.vnet.ibm.com>
On Fri, 2012-05-04 at 14:30 -0700, Nishanth Aravamudan wrote:
> Well, it is the case that libvirt does use it, and libvirt is used
> pretty widely (or so it seems to me). I don't use it (cpusets or libvirt
> :) either, but it seems like we should either tell libvirt directly that
> cpusets are inappropriate for their use-case (once we figure out what
> exactly that is, and why they chose cpusets) or work with them to
> support their use-case?
Sure, lets start by getting their use-case, then see if cpuset is the
right solution and if so take it from there.
That said, the whole suspend/resume 'problem' does seem worth fixing and
is a very special case where we absolutely know we're going to get back
in the state we are in and userspace isn't actually running. So ideally
we'd go with the bhat's patch that skips the sched_domain rebuilds
entirely +- some bug-fixes ;-).
next prev parent reply other threads:[~2012-05-04 21:44 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
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 [this message]
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=1336167852.6509.90.camel@twins \
--to=a.p.zijlstra@chello.nl \
--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@linux.vnet.ibm.com \
--cc=nacc@us.ibm.com \
--cc=nikunj@linux.vnet.ibm.com \
--cc=paul@paulmenage.org \
--cc=paulmck@linux.vnet.ibm.com \
--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