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

[Xen-devel] need for ClearPageReserved() in blktap2 code

To: <jake.wires@xxxxxxxxxx>,<dmeyer@xxxxxxxxx>
Subject: [Xen-devel] need for ClearPageReserved() in blktap2 code
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Mon, 09 Aug 2010 16:47:28 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 09 Aug 2010 08:47:23 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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
Jake, Dutch,

while I can see the need for this on the ring pages, I have some
difficulty understanding why it needs to be invoked on the individual
data pages as they get removed from ring->foreign_map.map: I
understand that SetPageReserved() when inserting them is needed
(or at least desirable) since in the 2.6.18 and pv-ops trees the
balloon driver doesn't guarantee pages being returned from
alloc_empty_pages_and_page_vec() are marked reserved (which
minimally I consider an inconsistency). In our trees, the balloon
driver does guarantee this, but it expects the pages to also be
returned in reserved state - which blktap2 breaks because of
the arbitrary(?) clearing of the flag.

The question hence really is whether that clearing is really
necessary, i.e. whether the pages, when not in some
ring->foreign_map.map[], validly and reasonably can (should) be
considered non-reserved - to me it appears there's no need for
this.

Thanks for letting my know your thoughts on this,
Jan


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

<Prev in Thread] Current Thread [Next in Thread>