On 07/11/2012 02:33 PM, David Rientjes wrote: > 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,
barrios@bbox:~/linux-next$ size mm/compaction.o mm/migrate.o text data bss dec hex filename 8550 1114 4 9668 25c4 mm/compaction.o 10891 520 0 11411 2c93 mm/migrate.o It couldn't be a trivial on small system. > that's the only reason we don't enable it by default? AFAIK, that's all. Mel. Do you think others? > >>> 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 Of course. > 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? I agree it's an ideal but the problem is that it's too late. Once product is released, we have to recall all products in the worst case. The fact is that lumpy have helped high order allocation implicitly but we removed it without any notification or information. It's a sort of regression and we can't say them "Please report us if it happens". It's irresponsible, too. IMHO, at least, what we can do is to warn about it before it's too late. > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majord...@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: <a href=mailto:"d...@kvack.org";> em...@kvack.org </a> > -- Kind regards, Minchan Kim -- 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/
