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/
Home Products Support Community News


Re: [Xen-devel] RE: Ballooning up

To: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Subject: Re: [Xen-devel] RE: Ballooning up
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Mon, 13 Sep 2010 16:06:24 -0700
Cc: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>, Xen-devel@xxxxxxxxxxxxxxxxxxx, Daniel Kiper <dkiper@xxxxxxxxxxxx>, Konrad Wilk <konrad.wilk@xxxxxxxxxx>
Delivery-date: Mon, 13 Sep 2010 16:07:17 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <a36f32a9-f0f6-4744-b9bc-15a932170692@default>
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>
References: <4C85F973.2030007@xxxxxxxx 54eebb3a-f539-43be-8134-a969a4f671c4@default> <a36f32a9-f0f6-4744-b9bc-15a932170692@default>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100806 Fedora/3.1.2-1.fc13 Lightning/1.0b2pre Thunderbird/3.1.2
 On 09/13/2010 02:39 PM, Dan Magenheimer wrote:
> Also, looking at the latest code in xen/next-2.6.32, I see
> you have removed the balloon lock.  Isn't this necessary
> to ensure multiple vcpus aren't racing on adjusting the
> balloon size (and performing the hypercalls to do it)?
> IOW, are increase/decrease_reservation and the calls
> into the hypervisor thread-safe?

Yes, because they are all done within the same tasklet, so there's no
possibility of races.

> And, related especially if the lock goes away (repeat
> of question asked here
> http://lists.xensource.com/archives/html/xen-devel/2010-08/msg01664.html )
> wouldn't it be better to use a separate workqueue rather than
> the kernel default queue,

There's a preference to use the default queue unless there's a strong
reason to do otherwise, to stop proliferation of kernel tasks.  Is there
a strong reason to use a specific balloon workqueue?

>  and is there any reason to
> queue the work on every cpu rather than just one?

There's a keventd on every CPU, but work is queued on only one CPU at a
time - it tends to end up running on the CPU which requested the work to
be queued, but if it is already queued then it will be left as-is.

I am seeing something queuing delayed work at 1kHz continiously, at
least in dom0.  Haven't worked out what's going on there...


Xen-devel mailing list

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