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 from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/