Re: [Xen-devel] Proposed new "memory capacity claim" hypercall/feature

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 04.11.12 at 20:43, Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> wrote:
>>  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 we got here via questioning whether suppressing certain
activities (like tmem causing the allocator visible amount of
available memory) for a brief period of time would be acceptable,
and while that indeed depends on the overall latency of memory
allocation for the domain as a whole, I would be somewhat
tolerant for it to involve a longer suspension period on a highly
fragmented system.

But of course, if this can be made work uniformly, that would be
preferred.

Jan


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