[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1336167852.6509.90.camel@twins>
Date: Fri, 04 May 2012 23:44:12 +0200
From: Peter Zijlstra <a.p.zijlstra@...llo.nl>
To: Nishanth Aravamudan <nacc@...ux.vnet.ibm.com>
Cc: "Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>,
mingo@...nel.org, pjt@...gle.com, paul@...lmenage.org,
akpm@...ux-foundation.org, rjw@...k.pl, nacc@...ibm.com,
paulmck@...ux.vnet.ibm.com, tglx@...utronix.de,
seto.hidetoshi@...fujitsu.com, rob@...dley.net, tj@...nel.org,
mschmidt@...hat.com, berrange@...hat.com,
nikunj@...ux.vnet.ibm.com, vatsa@...ux.vnet.ibm.com,
linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
linux-pm@...r.kernel.org
Subject: Re: [PATCH v2 0/7] CPU hotplug, cpusets: Fix issues with cpusets
handling upon CPU hotplug
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 ;-).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists