lkml.org 
[lkml]   [2012]   [Jul]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2] mm: Warn about costly page allocation
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 majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
>


--
Kind regards,
Minchan Kim




\
 
 \ /
  Last update: 2012-07-11 08:42    [W:0.262 / U:0.648 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site