From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juergen Gross Subject: Re: [PATCH] Allow ACPI state change with active cpupools Date: Tue, 20 Mar 2012 15:46:31 +0100 Message-ID: <4F689847.1020709@ts.fujitsu.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Keir Fraser Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On 03/20/2012 03:30 PM, Keir Fraser wrote: > On 20/03/2012 13:35, "Juergen Gross" wrote: > >> On 03/20/2012 01:52 PM, Keir Fraser wrote: >>> That's quite a lot of bother. Firstly, this could probably be supported by a >>> global system_state type of variable indicating whether we are booting, >>> suspending, normal. Etc. Secondly I wonder whether you really need to care >>> about this detail from within the cpupool code? When you offline a CPU in >>> cpupool!=0, remember it. Put it back in the pool when it onlines, if the >>> pool still exists. Don't prevent a pool from being destroyed just because it >>> has offline cpus as members. Something like that? Or even always have the >>> cpupool code put onlined cpus in pool 0, and have the acpi suspend code >>> remember and restore pool memberships. >> Hmm. Using a global variable seems to be hacky. > I'm not so sure. Suspend/resume is a significant out-of-the-ordinary global > system state. Representing that in a state variable doesn't seem so bad. > There are other states we could fold into this, for example we have an > early_boot variable in arch/x86 which could become part of the state > enumeration. > >> I tried to find a clean >> solution >> for the problem. If the changes are too big in your opinion, I'll try to >> handle >> cpu offlining local to cpupools. > Is it better to have cpupools know about offlining/suspend, or have > offlining/suspend know about cpupools? I would have thought the latter makes > more sense since it is offlining/suspend which calls into the cpupool > subsystem. I thought of a more relaxed solution in the cpupool coding: Instead of allowing to offline a cpu only if it is in Pool-0, I would allow it if: - the cpu is not the last one in the cpupool - or no domain is active in the cpupool (this would include the suspend case, where all domains are paused) Together with your proposal to remember the cpupool for an offlined cpu to add it again when it is onlined the handling should be rather simple and local. Juergen -- Juergen Gross Principal Developer Operating Systems PDG ES&S SWE OS6 Telephone: +49 (0) 89 3222 2967 Fujitsu Technology Solutions e-mail: juergen.gross@ts.fujitsu.com Domagkstr. 28 Internet: ts.fujitsu.com D-80807 Muenchen Company details: ts.fujitsu.com/imprint.html