WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [Patch 1/6] Cpupools: hypervisor part

To: Juergen Gross <juergen.gross@xxxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [Patch 1/6] Cpupools: hypervisor part
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Tue, 20 Apr 2010 13:45:53 +0100
Cc:
Delivery-date: Tue, 20 Apr 2010 05:46:52 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4BCD7623.1030507@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcrgbYP8Uc7GJ4wbTGaWVHQ92Pdc7QAGeWZj
Thread-topic: [Xen-devel] [Patch 1/6] Cpupools: hypervisor part
User-agent: Microsoft-Entourage/12.24.0.100205
Juergen,

I don't think there's any need to change the domain creation interfaces.
Drop new domains into a default pool, and then they can moved out (even
immediately) by further control operations. This will avoid changes to the
domain-creation public and private interfaces.

Also, you merge the cpu_add_remove_lock into a new cpupool_lock. That's not
actually safe since cpu_add_remove_lock is held on entry to
stopmachine_run(). Hence I assume now cpupool_lock is, and the only way to
avoid deadlock possibilities would be for everyone to only spin_trylock on
cpupool_lock, which isn't the case in your patch. Otherwise stopmachine_run
can hang waiting for a CPU to enter its smr handler, while that CPU is
waiting for the cpupool_lock to be released: a deadlock scenario.

I think you'll really need to find a method of synchronisation with cpu
hotplug which does not involve a lock that is held across stopmachine_run().
My first suggestion in this respect would be to take a look at
cpu_disable_scheduler(). This function deschedules vcpus from a cpu being
offlined, and notice you can go fairly hogwild with minimal locking
restrictions because everyone else is in a stopmachine 'safe place' with
irqs disabled. So they cannot concurrently conflict with you.

So hooking yourself off cpu_disable_scheduler(), or adding some other new
call-out from the end of __cpu_disable(), is quite probably the way to go to
update cpupool info, break affinities, or whatever else you need to do.

 -- Keir


On 20/04/2010 10:38, "Juergen Gross" <juergen.gross@xxxxxxxxxxxxxx> wrote:




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>