From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: Proposed new "memory capacity claim" hypercall/feature Date: Thu, 08 Nov 2012 22:32:32 +0000 Message-ID: References: <563639fd-fc13-49cd-88cf-431244534c2f@default> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <563639fd-fc13-49cd-88cf-431244534c2f@default> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Dan Magenheimer , Jan Beulich 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 08/11/2012 19:16, "Dan Magenheimer" wrote: >> Yes, this clearly prohibits unlimited batches. But not being able to >> schedule should be less restrictive than not being able to run >> softirqs, so I'd still put under question whether the limit shouldn't >> be bumped. > > Wait, please define unlimited. > > I think we are in agreement from previous discussion that, to solve > the TOCTOU race, the heap_lock must be held for the entire allocation > for a domain creation. True? It's pretty obvious that this isn't going to be possible in the general case. E.g., a 40G domain being created out of 4k pages (eg. Because memory is fragmented) is going to be at least 40G/4k == 10M heap operations. Say each takes 10ns, which would be quick, we're talking 100ms of cpu work. Holding a lock that long can't be recommended really. -- Keir