WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Design question for PV superpage support

To: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Subject: Re: [Xen-devel] Design question for PV superpage support
From: Mick Jordan <Mick.Jordan@xxxxxxx>
Date: Tue, 03 Mar 2009 09:06:31 -0800
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, Dave McCracken <dcm@xxxxxxxx>, Xen Developers List <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 03 Mar 2009 09:07:11 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <a6ec1b4a-f245-4b42-9c63-5b16877af761@default>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <a6ec1b4a-f245-4b42-9c63-5b16877af761@default>
Reply-to: Mick.Jordan@xxxxxxx
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.16 (X11/20080807)
On 03/03/09 06:33, Dan Magenheimer wrote:
In general, I think the guest should assume that large page 
mappings are 
merely an optimization that (a) might not be possible on domain start 
due to machine memory fragmentation and (b) that this condition might 
also occur on restore. Given these, it must always be prepared to 
function with 4K pages, which implies that it would need to preserve 
enough page table frame memory to be able revert from large 
to small pages.

Mick
    

Do you disagree with my assertion that use of 2MB pages is
almost always an attempt to eke out a performance improvement,
that emulating 2MB pages with fragmented 4KB pages is likely
slower than just using 4KB pages to start with, and thus
that "must always be prepared to function with 4KB pages"
should NOT occur silently (if at all)?
  
I agree with the first statement. I'm not sure what you mean by "emulate 2MB pages with fragmented 4K pages" unless you assume nested page table support or you just mean falling back to 4K pages. As for whether a change should be silent, I'm less clear on that. I certainly wouldn't consider it a fatal condition requiring domain termination, That position is consistent with the "optimization not correctness" view of using large tables. However, a guest might want to indicate in some way that it has downgraded
BTW, thinking ahead to ballooning with 2MB pages, are we prepared
to assume that a relinquished 2MB page can't be fragmented?
While this may be appealing for systems where nearly all
guests are using 2MB pages, systems where the 2MB guest is
an odd duck might suffer substantially by making that
assumption.
  
Agreed. All of this really only becomes an issue when memory is overcommitted. Unfortunately, that is precisely when 2MB machine contiguous pages are likely to be difficult to find.

Mick

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel