[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] RE: Ballooning up



 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...

    J

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.