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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 31.10.12 at 17:51, Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> wrote:
> To look at it another way, the code in alloc_heap_page()
> contained within the loop:
> 
>       for ( i = 0; i < (1 << order); i++ )
> 
> may be already unacceptable, even _after_ the patch, if
> order==26 (a fictional page size just for this illustration)
> because the heap_lock will be held for a very very long time.
> (In fact for order==20, 1GB pages, it could already be a
> problem.)

A million iterations doing just a few memory reads and writes
(not even atomic ones afaics) doesn't sound that bad. And
order-18 allocations (which is what 1Gb pages really amount
to) are the biggest ever happening (post-boot, if that matters).

You'll get much worse behavior if these large order allocations
fail, and the callers have to fall back to smaller ones.

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).

Jan


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