From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH] Add hypercall to mark superpages to improve performance Date: Sun, 2 May 2010 16:54:56 -0700 Message-ID: References: <201005021634.56315.dcm@mccr.org> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <201005021634.56315.dcm@mccr.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Dave McCracken Cc: Jeremy Fitzhardinge , Xen Developers List List-Id: xen-devel@lists.xenproject.org On 02/05/2010 14:34, "Dave McCracken" wrote: > One outstanding issue I see is how to handle readonly mappings. If we follow > the model of regular page typecount, readonly mappings of superpages would not > conflict with the "conflicts with superpage" type. This means a subsequent > attempt to change it to a read/write mapping could fail, just like with a > regular page. Or we could count all mappings of superpages as if they were > read/write. I'd keep an extra refcount in superpage_info to track read-only mappings (or all superpage mappings, as page->count_info does for 4kB mappings). It's trivial extra space and avoids having unexpected extra restrictions on read-only superpage mappings. > What are your thoughts? It seems fairly simple and elegant to me, and at this > point I don't see any big holes in it. It does mean that creating/destroying pagetable pages causes an extra locked read-modify-write cycle on a non-local cacheline (superpage_info refcount). Would this be significant? Not sure. I guess we'd only be doing it for guests with the superpage capability configured, and we could do some performance comparisons with the capability enabled/disabled. I think overall I quite like your suggestion. -- Keir