Re: [PATCH 6 of 8 [RFC]] libxc: introduce xc_domain_move_memory

[Dario Faggioli <dario.faggioli@citrix.com>]

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

On gio, 2013-05-02 at 16:13 +0100, Tim Deegan wrote:
> At 16:07 +0100 on 02 May (1367510834), George Dunlap wrote:
>
> > Hmm -- isn't it the case that if there is not *free* memory lying around 
> > somewhere, then this operation is fairly pointless?  What will happen is 
> > that after freeing batch 0, "allocate new batch 1" will get that 
> > memory.  So copying it to a temporary buffer in dom0 seems like not a 
> > particularly useful thing to do -- it should try to allocate a new 
> > buffer to copy into directly, and if that fails, just say "No point 
> > trying -- no empty memory to move into."
> 
George, good point, checking for free memory is something I did not
think about, but it's necessary for this while thing to be meaningful.
This could be tricky to do in the right way, due to the well known races
we have when dealing with memory at the toolstack level, but I'll give
it a thought, thanks. :-)

However...

> Sure, that's better, as long as the temporary bump in the VM's max_pages
> is acceptable to the rest of the toolstack. :)
> 
... This that Tim is saying is the main reason I'm going through a
temporary buffer in Dom0: I can't be sure that, if failing allocating
more memory for the domain before freeing it, that comes from the host
being actually out-of-memory, or from the fact that I'm hitting
max_pages.

That's why I went for the "deallocate first" approach. I can investigate
what temporarily bumping the page limit could mean, but I think I like
what Tim proposed in his first e-mail better...

Thanks and Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.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