[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Proposed new "memory capacity claim" hypercall/feature
>>> 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |