From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: Proposed new "memory capacity claim" hypercall/feature Date: Fri, 02 Nov 2012 09:30:14 +0000 Message-ID: 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: <50939A1502000078000A5F61@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , Dan Magenheimer Cc: TimDeegan , Olaf Hering , IanCampbell , Konrad Rzeszutek Wilk , George Dunlap , Ian Jackson , George Shuklin , xen-devel@lists.xen.org, DarioFaggioli , Kurt Hackel , Zhigang Wang List-Id: xen-devel@lists.xenproject.org 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. -- Keir