xen-devel
[Xen-devel] RE: Tmem vs order>0 allocation, workaround RFC
To: |
Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Jan Beulich <JBeulich@xxxxxxxxxx> |
Subject: |
[Xen-devel] RE: Tmem vs order>0 allocation, workaround RFC |
From: |
Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> |
Date: |
Mon, 15 Feb 2010 07:55:35 -0800 (PST) |
Cc: |
George Dunlap <George.Dunlap@xxxxxxxxxxxxx>, 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:58:29 -0800 |
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
In-reply-to: |
<C79F1B58.A196%keir.fraser@xxxxxxxxxxxxx> |
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: |
<2af13319-6b44-44e2-ab62-a0615208cf64@default C79F1B58.A196%keir.fraser@xxxxxxxxxxxxx> |
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
> 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.
Understood.
If we eliminate this case, can you think of any others that
are asymmetric, except possibly very uncommon ones?
> > 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.
Other than the above, can you (or Jan? or others?) think of
other cases where it won't work in practice? If not, it's
at least worth a try to see if Jan's test cases continue
to see a problem.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- [Xen-devel] Tmem vs order>0 allocation, workaround RFC, Dan Magenheimer
- RE: [Xen-devel] Tmem vs order>0 allocation, workaround RFC, Dan Magenheimer
- [Xen-devel] Re: Tmem vs order>0 allocation, workaround RFC, Keir Fraser
- [Xen-devel] RE: Tmem vs order>0 allocation, workaround RFC, Dan Magenheimer
- [Xen-devel] Re: Tmem vs order>0 allocation, workaround RFC, Keir Fraser
- [Xen-devel] RE: Tmem vs order>0 allocation, workaround RFC,
Dan Magenheimer <=
- [Xen-devel] Re: Tmem vs order>0 allocation, workaround RFC, Keir Fraser
- [Xen-devel] RE: Tmem vs order>0 allocation, workaround RFC, Dan Magenheimer
- [Xen-devel] RE: Tmem vs order>0 allocation, workaround RFC, Jan Beulich
- [Xen-devel] RE: Tmem vs order>0 allocation, workaround RFC, Dan Magenheimer
- [Xen-devel] RE: Tmem vs order>0 allocation, workaround RFC, Jan Beulich
- [Xen-devel] RE: Tmem vs order>0 allocation, workaround RFC, Dan Magenheimer
- [Xen-devel] RE: Tmem vs order>0 allocation, workaround RFC, Jan Beulich
- [Xen-devel] RE: Tmem vs order>0 allocation, workaround RFC, Dan Magenheimer
- Re: [Xen-devel] RE: Tmem vs order>0 allocation, workaround RFC, Konrad Rzeszutek Wilk
|
|
|