Re: Proposed new "memory capacity claim" hypercall/feature

[Dario Faggioli <raistlin@linux.it>]

[-- Attachment #1.1: Type: text/plain, Size: 1741 bytes --]

On Mon, 2012-10-29 at 22:35 +0000, Tim Deegan wrote:
> At 10:06 -0700 on 29 Oct (1351505175), Dan Magenheimer wrote:
> > In the case of a dying domain, a XENMEM_release operation
> > is implied and must be executed by the hypervisor.
> > 
> > Ideally, the quantity of unclaimed memory for each domain and
> > for the system should be query-able.  This may require additional
> > memory_op hypercalls.
> > 
> > I'd very much appreciate feedback on this proposed design!
> 
> As I said, I'm not opposed to this, though even after reading through
> the other thread I'm not convinced that it's necessary (except in cases
> where guest-controlled operations are allowed to consume unbounded
> memory, which frankly gives me the heebie-jeebies).
> 
Let me also ask something.

Playing with NUMA systems I've been in the situation where it would be
nice to know not only how much free memory we have in general, but how
much free memory there is in a specific (set of) node(s), and that in
many places, from the hypervisor, to libxc, to top level toolstack.

Right now I ask this to Xen, but that is indeed prone to races and
TOCTOU issues if we allow for domain creation and ballooning
(tmem/paging/...) to happen concurrently between themselves and between
each other (as noted in the long thread that preceded this one).

Question is, the "claim" mechanism you're proposing is by no means NUMA
node-aware, right?

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)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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