From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758105Ab2BMUtY (ORCPT ); Mon, 13 Feb 2012 15:49:24 -0500 Received: from e28smtp08.in.ibm.com ([122.248.162.8]:48416 "EHLO e28smtp08.in.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758070Ab2BMUtX (ORCPT ); Mon, 13 Feb 2012 15:49:23 -0500 Message-ID: <4F397745.8000003@linux.vnet.ibm.com> Date: Tue, 14 Feb 2012 02:19:09 +0530 From: "Srivatsa S. Bhat" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: paulmck@linux.vnet.ibm.com CC: Peter Zijlstra , Ingo Molnar , paul@paulmenage.org, rjw@sisk.pl, tj@kernel.org, frank.rowand@am.sony.com, pjt@google.com, tglx@linutronix.de, lizf@cn.fujitsu.com, prashanth@linux.vnet.ibm.com, vatsa@linux.vnet.ibm.com, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, "akpm@linux-foundation.org" Subject: Re: [PATCH 0/4] CPU hotplug, cpusets: Fix CPU online handling related to cpusets References: <20120207185411.7482.43576.stgit@srivatsabhat.in.ibm.com> <1328671335.2482.72.camel@laptop> <4F32174E.2050207@linux.vnet.ibm.com> <20120209075701.GE18387@elte.hu> <4F3386E9.7090606@linux.vnet.ibm.com> <20120209151158.GA22489@elte.hu> <1328889127.25989.14.camel@laptop> <20120210165338.GI2458@linux.vnet.ibm.com> <4F394CC9.6010103@linux.vnet.ibm.com> <20120213203929.GQ2864@linux.vnet.ibm.com> In-Reply-To: <20120213203929.GQ2864@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit x-cbid: 12021320-2000-0000-0000-000006666611 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/14/2012 02:09 AM, Paul E. McKenney wrote: > On Mon, Feb 13, 2012 at 11:17:53PM +0530, Srivatsa S. Bhat wrote: >> On 02/10/2012 10:23 PM, Paul E. McKenney wrote: >> >>> On Fri, Feb 10, 2012 at 04:52:07PM +0100, Peter Zijlstra wrote: >>>> On Thu, 2012-02-09 at 16:11 +0100, Ingo Molnar wrote: >>>> >>>>>> My understanding of the code is that when a CPU is taken >>>>>> offline, it is removed from all the cpusets and then the >>>>>> scan_for_empty_cpusets() function is run to move tasks from >>>>>> empty cpusets to their parent cpusets. >>>>> >>>>> Why is that done that way? offlining a CPU should be an >>>>> invariant as far as cpusets are concerned. >>>> >>>> Can't, tasks need to run someplace. There's two choices, add a still >>>> online cpu to the now empty cpuset or move the tasks to a parent that >>>> still has online cpus. >>>> >>>> Both are destructive. >>> >>> OK, I will ask the stupid question... Hey, somebody has to! ;-) >>> >>> Would it make sense for offlining the last CPU in a cpuset to be >>> destructive, but to allow offlining of a non-last CPU to be reversible? >>> >>> For example, assume that cpuset A has CPUs 0 and 1, and cpuset B has >>> 1, 2, and 3. Then offlining any single CPU and then onlining it would >>> restore the cpusets to their original state. Offlining both CPUs 0 and 1 >>> would be destructive to cpuset A, so that onlining those two CPUs would >>> leave any tasks in cpuset A in some ancestor of cpuset A, and would >>> leave cpuset A with no assigned CPUs. However, that same operation >>> (offlining both CPUs 0 and 1, then onlining them) would restore cpuset >>> B to its original state, covering CPUs 1, 2, and 3. >> >> But how would this scheme help us? During suspend, all non-boot CPUs are >> taken offline. Which means, it would be destructive to any cpuset that >> didn't originally contain CPU0 (even when using the above scheme). So, upon >> resume, it is still not the same as how it was before suspend. > > Yep, it would only help for incremental cases. Or if all cpusets had > CPU 0 in them. So preserving cpusets across suspend will require a > bigger hammer. > Hehe ;-) Regards, Srivatsa S. Bhat