linux-kernel - Re: [PATCH] mm: clarify COMPACTION Kconfig text

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.10.1608251524140.48031@chino.kir.corp.google.com>
Date:   Thu, 25 Aug 2016 15:34:54 -0700 (PDT)
From:   David Rientjes <rientjes@...gle.com>
To:     Michal Hocko <mhocko@...nel.org>
cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Mel Gorman <mgorman@...e.de>, Joonsoo Kim <js1304@...il.com>,
        Vlastimil Babka <vbabka@...e.cz>,
        Markus Trippelsdorf <markus@...ppelsdorf.de>,
        linux-mm@...ck.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [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.