xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
To: Keir Fraser <keir.xen@gmail.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [PATCH] Allow ACPI state change with active cpupools
Date: Tue, 20 Mar 2012 15:46:31 +0100	[thread overview]
Message-ID: <4F689847.1020709@ts.fujitsu.com> (raw)
In-Reply-To: <CB8E44F6.2ECBE%keir.xen@gmail.com>

On 03/20/2012 03:30 PM, Keir Fraser wrote:
> On 20/03/2012 13:35, "Juergen Gross"<juergen.gross@ts.fujitsu.com>  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

  reply	other threads:[~2012-03-20 14:46 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-20 12:15 [PATCH] Allow ACPI state change with active cpupools Juergen Gross
2012-03-20 12:52 ` Keir Fraser
2012-03-20 13:35   ` Juergen Gross
2012-03-20 14:30     ` Keir Fraser
2012-03-20 14:46       ` Juergen Gross [this message]
2012-03-20 14:55         ` Keir Fraser
2012-03-21 13:46           ` Juergen Gross

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=4F689847.1020709@ts.fujitsu.com \
    --to=juergen.gross@ts.fujitsu.com \
    --cc=keir.xen@gmail.com \
    --cc=xen-devel@lists.xensource.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).