[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



> 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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.