[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |