[Xen-devel] RE: Tmem vs order>0 allocation, workaround RFC

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

> From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
> > 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.
> 
> I don't see how that necessarily works. Pages can be allocated in
> order>0
> chunks and freed order==0, so even that last 1% can get fragmented. For
> example, guests get their memory allocated in 2MB chunks where
> possible; but
> their balloon drivers may then free arbitrary 4kB pages within those
> chunks.

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?

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.

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