lkml.org 
[lkml]   [2016]   [Aug]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] mm: clarify COMPACTION Kconfig text
On Thu, 25 Aug 2016, Michal Hocko wrote:

> > I don't believe it has been an issue in the past for any archs that
> > don't use thp.
>
> Well, fragmentation is a real problem and order-0 reclaim will be never
> anywhere close to reliably provide higher order pages. Well, reclaiming
> a lot of memory can increase the probability of a success but that
> can quite often lead to over reclaim and long stalls. There are other
> sources of high order requests than THP so this is not about THP at all
> IMHO.
>

Would it be possible to list the high-order allocations you are concerned
about other than thp that doesn't have fallback behavior like skbuff and
slub allocations? struct task_struct is an order-1 allocation and there
may be order-1 slab bucket usage, but what is higher order or requires
aggressive compaction to allocate? Surely you're not suggesting that
order-0 reclaim cannot form order-1 memory. I am concerned about kernels
that require a small memory footprint and cannot enable all of
CONFIG_COMPACTION and CONFIG_MIGRATION. Embedded devices are not a
negligible minority of kernels.

> > , CONFIG_MIGRATION. Migration has a
> > dependency of NUMA or memory hot-remove (not all popular). Compaction can
> > defragment memory within single zone without reliance on NUMA.
>
> I am not sure I am following you here.
> MIGRATION depends on (NUMA || ARCH_ENABLE_MEMORY_HOTREMOVE || COMPACTION || CMA) && MMU
>

Embedded device may be UMA and not care for memory hotplug or failure
handling and rely solely on order-0 and order-1 memory.

\
 
 \ /
  Last update: 2016-09-17 09:57    [W:0.105 / U:0.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site