Re: [Xen-devel] domain creation vs querying free memory (xend and xl)

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

(Rats, thought I sent this out yesterday...)

> From: Dario Faggioli [mailto:raistlin@xxxxxxxx]
> Sent: Friday, September 28, 2012 10:08 AM
> To: George Shuklin
> Cc: xen-devel@xxxxxxxxxxxxx
> Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl)
> 
> On Thu, 2012-09-27 at 19:24 +0400, George Shuklin wrote:
> > not sure about xl/xm, but xapi performs one start at time, so there is
> > no race between domains for memory or other resources.

Oops, sorry, I missed this part of the thread because I wasn't directly
cc'ed and am behind on my xen-devel reading...

> IIRC, xl has a vary coarse grain locking mechanism in place for domain
> creation too. As a result of that, you shouldn't be able to create two
> domains at the same time, which should be enough for preventing the
> situation described in the original e-mail for occurring.
> 
> Looking at acquire_lock() and release_lock() (and at where they are
> called) in xl code should clarify whether or not that is enough to
> actually avoid the race (which I think it is, but I might be wrong :-D).

This sounds like a pretty serious limitation, especially if it applies
to migration as well as creation (or a combination)... I hope it is not
a regression from xm to xl.  For example, suppose a data center
is trying to do a planned downtime for machine X by force-migrating
all guests to machine Y.  It sounds like xl would serialize this?

> That being said, there still is the room for races, although not wrt
> domain creation, as, for instance, there isn't any synchronization
> between creation and ballooning, which both manipulate memory. So, maybe
> thinking about some kind of reservation-based/transactional mechanism at
> some level might make actual sense.

Which is mostly the reason I am interested ;-) though solving
the superset of my problem is probably a good thing as well.

Dan

> Unfortunately, I've no idea about how xm works in that respect.
> 
> Hope this at least help clarifying the situation a bit. :-)
> 
> Thanks and Regards,
> Dario
> 
> --
> <<This happens because I choose it to happen!>> (Raistlin Majere)
> -----------------------------------------------------------------
> Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
> Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel