On Thu, May 12, 2011 at 11:27:04AM -0500, Christoph Lameter wrote: > On Thu, 12 May 2011, James Bottomley wrote: > > > However, the fact remains that this seems to be a slub problem and it > > needs fixing. > > Why are you so fixed on slub in these matters? Its an key component but > there is a high interaction with other subsystems. There was no recent > change in slub that changed the order of allocations. There were changes > affecting the reclaim logic. Slub has been working just fine with the > existing allocation schemes for a long time. It should work just fine when compaction is enabled. The COMPACTION=n case would also work decent if we eliminate the lumpy reclaim. Lumpy reclaim tells the VM to ignore all young bits in the pagetables and take everything down in order to generate the order 3 page that SLUB asks. You can't expect decent behavior the moment you take everything down regardless of referenced bits on page and young bits in pte. I doubt it's new issue, but lumpy may have become more or less aggressive over time. Good thing, lumpy is eliminated (basically at runtime, not compile time) by enabling compaction. -- 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
