On (10/07/07 11:46), Christoph Lameter didst pronounce: > On Tue, 10 Jul 2007, Nick Piggin wrote: > > > I realise in your pragmatic approach, you are encouraging users to > > put fallbacks in place in case a higher order page cannot be allocated, > > but I don't think either higher order pagecache or higher order slubs > > have such fallbacks (fsblock or a combination of fsblock and higher > > order pagecache could have, but...). > > We have run mm kernels for month now without the need of a fallback. I > purpose of ZONE_MOVABLE was to guarantee that higher order pages could be > reclaimed and thus make the scheme reliable? >
That and they would be available within a specified limit. With grouping pages by mobility, high order pages will be available but it's workload dependant on how many there will be. This sort of predictability is important for hugepages and memory unplug although it's of less relevance to order-3 and order-4 users. > The experience so far shows that the approach works reliably. If there are > issues then they need to be fixed. Putting in workarounds in other places > such as in fsblock may just be hiding problems if there are any. I think fsblock as it stands would gain from grouping pages by mobility. It could use high order pages where they were available and fallback to using the slower vmap approach when they weren't. I don't see why highorder page cache and fsblock would be mutually exclusive. For that matter, I don't see why any of these approachs are mutually exclusive with what Andrea is doing other than having more than one way of skinning a cat in the kernal at the same time might be confusing. -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
