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] Re: Tmem vs order>0 allocation, workaround RFC

To: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>
Subject: [Xen-devel] Re: Tmem vs order>0 allocation, workaround RFC
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Mon, 15 Feb 2010 15:40:08 +0000
Cc: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>, "kurt.hackel@xxxxxxxxxx" <kurt.hackel@xxxxxxxxxx>, Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>, Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>, Patrick Colp <pjcolp@xxxxxxxxx>, Grzegorz Milos <gm281@xxxxxxxxx>, Andrew Peace <Andrew.Peace@xxxxxxxxxxxxx>
Delivery-date: Mon, 15 Feb 2010 07:41:01 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <2af13319-6b44-44e2-ab62-a0615208cf64@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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcquS7DORsdCgH7yRfaDCrCX5V69AAACXYD2
Thread-topic: Tmem vs order>0 allocation, workaround RFC
User-agent: Microsoft-Entourage/12.23.0.091001
On 15/02/2010 14:31, "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx> wrote:

> Good point.  BUT... do you know of any other asymmetric
> allocs/frees?  Since the 2MB allocation does fall back
> if it fails (to 4K I think?, if the patch is modified
> to restrict the "zone" to order>0&&order<9 will that
> be sufficient?

Even though that one can fall back, the point is that even one asymmetric
alloc/free (and that is by far going to be the most common one) can hoover
up the 1% 'pool' and fragment it, so that allocations that cannot fall back
can no longer use the pool.

> I know this is quite a hack...  I don't like it much
> either.  But I expect the process of restructuring all
> data structures to limit them to order==0 to take a long
> time with an even longer bug tail (AND be a whack-a-mole
> game in the future unless we disallow order>0 entirely).
> In that light (and with the low impact of this workaround),
> this hack may be just fine for a while.

Well, I think it's not only not very nice but also dubious whether it will
work in practice very well.

 -- Keir



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