From mboxrd@z Thu Jan  1 00:00:00 1970
From: Keir Fraser <keir.xen@gmail.com>
Subject: Re: Proposed new "memory capacity claim"
	hypercall/feature
Date: Thu, 08 Nov 2012 08:18:29 +0000
Message-ID: <CCC11B55.4443A%keir.xen@gmail.com>
References: <509B74B402000078000A7206@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <509B74B402000078000A7206@nat28.tlf.novell.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Jan Beulich <JBeulich@suse.com>, Dan Magenheimer <dan.magenheimer@oracle.com>
Cc: TimDeegan <tim@xen.org>, Olaf Hering <olaf@aepfle.de>, Keir Fraser <keir@xen.org>, IanCampbell <Ian.Campbell@citrix.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, George Dunlap <George.Dunlap@eu.citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>, George Shuklin <george.shuklin@gmail.com>, xen-devel@lists.xen.org, DarioFaggioli <raistlin@linux.it>, Kurt Hackel <kurt.hackel@oracle.com>, Zhigang Wang <zhigang.x.wang@oracle.com>
List-Id: xen-devel@lists.xenproject.org

On 08/11/2012 08:00, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 07.11.12 at 23:17, Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
>> It appears that the attempt to use 2MB and 1GB pages is done in
>> the toolstack, and if the hypervisor rejects it, toolstack tries
>> smaller pages.  Thus, if physical memory is highly fragmented
>> (few or no order>=9 allocations available), this will result
>> in one hypercall per 4k page so a 256GB domain would require
>> 64 million hypercalls.  And, since AFAICT, there is no sane
>> way to hold the heap_lock across even two hypercalls, speeding
>> up the in-hypervisor allocation path, by itself, will not solve
>> the TOCTOU race.
> 
> No, even in the absence of large pages, the tool stack will do 8M
> allocations, just without requesting them to be contiguous.
> Whether 8M is a suitable value is another aspect; that value may
> predate hypercall preemption, and I don't immediately see why
> the tool stack shouldn't be able to request larger chunks (up to
> the whole amount at once).

It is probably to allow other dom0 processing (including softirqs) to
preempt the toolstack task, in the case that the kernel was not built with
involuntary preemption enabled (having it disabled is the common case I
believe?). 8M batches may provide enough returns to user space to allow
other work to get a look-in.



> Jan
>