On Wed, 11 Jul 2012, Minchan Kim wrote: > > Should we consider enabling CONFIG_COMPACTION in defconfig? If not, would > > I hope so but Mel didn't like it because some users want to have a smallest > kernel if they don't care of high-order allocation. > CONFIG_COMPACTION adds 0.1% to my kernel image using x86_64 defconfig, that's the only reason we don't enable it by default? > > it be possible with a different extfrag_threshold (and more aggressive > > when things like THP are enabled)? > > Anyway, we should enable compaction for it although the system doesn't > care about high-order allocation and it ends up make bloting kernel unnecessary. > The problem with this approach (and the appended patch) is that we can't define a system that "doesn't care about high-order allocations." Even if you discount thp, an admin has no way of knowing how many high-order allocations his or her kernel will be doing and it will change between kernel versions. Almost 50% of slab caches on my desktop machine running with slub have a default order greater than 0. So I don't believe that adding this warning will be helpful and will simply lead to confusion. > I tend to agree Andrew and your concern but I don't have a good idea but > alert vague warning message. Anyway, we need *alert* this fact which removed > lumpy reclaim for being able to disabling CONFIG_COMPACTION. Can we ignore the fact that lumpy reclaim was removed and look at individual issues as they arise and address them by fixing the VM or by making a case for enabling CONFIG_COMPACTION by default? -- 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>