On Saturday 15 September 2007 03:52, Christoph Lameter wrote: > On Fri, 14 Sep 2007, Nick Piggin wrote: > > > > [*] ok, this isn't quite true because if you can actually put a hard > > > > limit on unmovable allocations then anti-frag will fundamentally help > > > > -- get back to me on that when you get patches to move most of the > > > > obvious ones. > > > > > > We have this hard limit using ZONE_MOVABLE in 2.6.23. > > > > So we're back to 2nd class support. > > 2nd class support for me means a feature that is not enabled by default > but that can be enabled in order to increase performance. The 2nd class > support is there because we are not yet sure about the maturity of the > memory allocation methods. I'd rather an approach that does not require all these hacks. > > > Reserve pools as handled (by the not yet available) large page pool > > > patches (which again has altogether another purpose) are not a limit. > > > The reserve pools are used to provide a mininum of higher order pages > > > that is not broken down in order to insure that a mininum number of the > > > desired order of pages is even available in your worst case scenario. > > > Mainly I think that is needed during the period when memory > > > defragmentation is still under development. > > > > fsblock doesn't need any of those hacks, of course. > > Nor does mine for the low orders that we are considering. For order > > MAX_ORDER this is unavoidable since the page allocator cannot manage such > large pages. It can be used for lower order if there are issues (that I > have not seen yet). Or we can just avoid all doubt (and doesn't have arbitrary limitations according to what you think might be reasonable or how well the system actually behaves). - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
