xen-devel
[Xen-devel] Tmem vs order>0 allocation, workaround RFC
To: |
Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Jan Beulich <JBeulich@xxxxxxxxxx> |
Subject: |
[Xen-devel] Tmem vs order>0 allocation, workaround RFC |
From: |
Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> |
Date: |
Fri, 12 Feb 2010 09:24:49 -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: |
Fri, 12 Feb 2010 09:27:21 -0800 |
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 |
I just had an idea for a workaround that might be low enough
impact to get in for 4.0 and allow tmem to be enabled by
default. I think it will not eliminate the fragmentation
problem entirely, but would greatly reduce the probability
of it causing problems for domain creation/migration when tmem
is enabled, and possibly for the other memory utilization
features as well.
Simply, avail_heap_pages would fail if total_avail_pages
is less than 1%(?) of the total memory on the system AND
the request is order==0. Essentially, this is reserving
a "zone" for order>0 allocations.
It could be tied to tmem_enabled but, as previously discussed,
even fragmentation from frequent ballooning can fragment
memory and cause problems for domain creation/migration...
and since, without memory utilization features it is highly
unlikely that a system will "accidentally" pack in enough
domains to use between 99% and 100% of physical memory anyway,
always enabling this restriction would affect very very few
systems.
Comments? I'm not sure I've thought this all the way
through and certainly haven't tested it yet, but it
seems like it should be easy to implement in a low-impact
patch.
Thanks,
Dan
_______________________________________________
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
|
|
|