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

[Dan Magenheimer <dan.magenheimer@oracle.com>]

> From: Keir Fraser [mailto:keir@xen.org]
> Sent: Friday, November 02, 2012 3:30 AM
> To: Jan Beulich; Dan Magenheimer
> Cc: Olaf Hering; IanCampbell; George Dunlap; Ian Jackson; George Shuklin; DarioFaggioli; xen-
> devel@lists.xen.org; Konrad Rzeszutek Wilk; Kurt Hackel; Mukesh Rathor; Zhigang Wang; TimDeegan
> Subject: Re: Proposed new "memory capacity claim" hypercall/feature
> 
> On 02/11/2012 09:01, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
> > Plus, if necessary, that loop could be broken up so that only the
> > initial part of it gets run with the lock held (see c/s
> > 22135:69e8bb164683 for why the unlock was moved past the
> > loop). That would make for a shorter lock hold time, but for a
> > higher allocation latency on large oder allocations (due to worse
> > cache locality).
> 
> In fact I believe only the first page needs to have its count_info set to !=
> PGC_state_free, while the lock is held. That is sufficient to defeat the
> buddy merging in free_heap_pages(). Similarly, we could hoist most of the
> first loop in free_heap_pages() outside the lock. There's a lot of scope for
> optimisation here.

(sorry for the delayed response)

Aren't we getting a little sidetracked here?  (Maybe my fault for
looking at whether this specific loop is fast enough...)

This loop handles only order=N chunks of RAM.  Speeding up this
loop and holding the heap_lock here for a shorter period only helps
the TOCTOU race if the entire domain can be allocated as a
single order-N allocation.

Domain creation is supposed to succeed as long as there is
sufficient RAM, _regardless_ of the state of memory fragmentation,
correct?

So unless the code for the _entire_ memory allocation path can
be optimized so that the heap_lock can be held across _all_ the
allocations necessary to create an arbitrary-sized domain, for
any arbitrary state of memory fragmentation, the original
problem has not been solved.

Or am I misunderstanding?

I _think_ the claim hypercall/subop should resolve this, though
admittedly I have yet to prove (and code) it.

Thanks,
Dan