[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Proposed new "memory capacity claim" hypercall/feature
> From: Keir Fraser [mailto:keir@xxxxxxx] > 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@xxxxxxxxxxxxx; 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@xxxxxxxx> 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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |