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/
Home Products Support Community News


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

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: RE: [Xen-devel] Design question for PV superpage support
From: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Date: Tue, 3 Mar 2009 18:09:39 +0000 (GMT)
Cc: Dave McCracken <dcm@xxxxxxxx>, Mick.Jordan@xxxxxxx, Xen Developers List <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 03 Mar 2009 10:10:19 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <49AD68C7.5000305@xxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> Dan Magenheimer wrote:
> > 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.
> Well, I still think that 4k pages are a ludicrously tiny unit 
> of memory 
> for Xen to be dealing with, and it shouldn't bother to get out of bed 
> for less than 2M.  If we treat 4k pages as the special case 
> then keeping 
> the Xen heap unfragmented at the 2M level should be fairly easy, no?

Probably true, though I suspect this is harder than it sounds.

Xen-devel mailing list