On Tue, 10 Jul 2012, Minchan Kim wrote: > > So I dunno, this all looks like we have a kernel problem and we're > > throwing our problem onto hopelessly ill-equipped users of that kernel? > > As you know, this patch isn't for solving regular high-order allocations. > As I wrote down, The problem is that we removed lumpy reclaim without any > notification for user who might have used it implicitly. And so now they're running with CONFIG_DEBUG_VM to try to figure out why they have seen a regression, which is required for your patch to have an effect? > If such user disable compaction which is a replacement of lumpy reclaim, > their system might be broken in real practice while test is passing. > So, the goal is that let them know it in advance so that I expect they can > test it stronger than old. > So what are they supposed to do? Enable CONFIG_COMPACTION as soon as they see the warning? When they have seen the warning a specific number of times? How much is "very few" high-order allocations over what time period? This is what anybody seeing these messages for the first time is going to ask. > Although they see the page allocation failure with compaction, it would > be very helpful reports. It means we need to make compaction more > aggressive about reclaiming pages. > If CONFIG_COMPACTION is disabled, then how will making compaction more aggressive about reclaiming pages help? Should we consider enabling CONFIG_COMPACTION in defconfig? If not, would it be possible with a different extfrag_threshold (and more aggressive when things like THP are enabled)? -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>