On Wed, May 11, 2011 at 03:27:11PM -0700, David Rientjes wrote: > On Wed, 11 May 2011, Mel Gorman wrote: > > > I agree with you that there are situations where plenty of memory > > means that that it'll perform much better. However, indications are > > that it breaks down with high CPU usage when memory is low. Worse, > > once fragmentation becomes a problem, large amounts of UNMOVABLE and > > RECLAIMABLE will make it progressively more expensive to find the > > necessary pages. Perhaps with patches 1 and 2, this is not as much > > of a problem but figures in the leader indicated that for a simple > > workload with large amounts of files and data exceeding physical > > memory that it was better off not to use high orders at all which > > is a situation I'd expect to be encountered by more users than > > performance-sensitive applications. > > > > In other words, we're taking one hit or the other. > > > > Seems like the ideal solution would then be to find how to best set the > default, and that can probably only be done with the size of the smallest > node since it has a higher liklihood of encountering a large amount of > unreclaimable slab when memory is low. > Ideally yes, but glancing through this thread and thinking on it a bit more, I'm going to drop this patch. As pointed out, SLUB with high orders has been in use with distributions already so the breakage is elsewhere. Patches 1 and 2 still make some sense but they're not the root cause. > <SNIP> -- Mel Gorman SUSE Labs -- 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
