From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Magenheimer Subject: Re: Proposed new "memory capacity claim" hypercall/feature Date: Sun, 4 Nov 2012 11:43:06 -0800 (PST) Message-ID: <7481128d-3f65-4cc3-ad96-1d4e9cd25094@default> References: <50939A1502000078000A5F61@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Keir Fraser , Jan Beulich Cc: TimDeegan , Olaf Hering , IanCampbell , Konrad Wilk , George Dunlap , Ian Jackson , George Shuklin , xen-devel@lists.xen.org, DarioFaggioli , Kurt Hackel , Zhigang Wang List-Id: xen-devel@lists.xenproject.org > 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" 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