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]
Date:   Thu, 24 Nov 2022 10:09:03 +0100
From:   Vlastimil Babka <vbabka@...e.cz>
To:     Roman Gushchin <roman.gushchin@...ux.dev>
Cc:     Christoph Lameter <cl@...ux.com>,
        David Rientjes <rientjes@...gle.com>,
        Joonsoo Kim <iamjoonsoo.kim@....com>,
        Pekka Enberg <penberg@...nel.org>,
        Hyeonggon Yoo <42.hyeyoo@...il.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Matthew Wilcox <willy@...radead.org>, patches@...ts.linux.dev,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 07/12] mm, slab: ignore SLAB_RECLAIM_ACCOUNT with
 CONFIG_SLUB_TINY

On 11/24/22 02:20, Roman Gushchin wrote:
> On Mon, Nov 21, 2022 at 06:11:57PM +0100, Vlastimil Babka wrote:
>> SLAB_RECLAIM_ACCOUNT caches allocate their slab pages with
>> __GFP_RECLAIMABLE and can help against fragmentation by grouping pages
>> by mobility, but on tiny systems mobility grouping is likely disabled
>> anyway and ignoring SLAB_RECLAIM_ACCOUNT might instead lead to merging
>> of caches that are made incompatible just by the flag.
>> 
>> Thus with CONFIG_SLUB_TINY, make SLAB_RECLAIM_ACCOUNT ineffective.
> 
> Hm, do you see disabling all kernel memory accounting functionality
> with COFNIG_SLUB_TINY? I'd say yes. But in this case need to be consistent
> and disable it alltogether.

SLAB_RECLAIM_ACCOUNT is kinda misnomer these days, as the only thing it does
is to add __GFP_RECLAIMABLE to cache's gfp flags for the page allocator's
mobility grouping. I guess the "ACCOUNT" part comes from being counted
towards SReclaimable (vs SUnreclaim) in /proc/meminfo.

So currently SLUB_TINY has no effect on MEMCG_KMEM (which you probably
meant). Using those two together has little sense and had I stumbled while
making this series upon a code that would become complicated, I would have
made SLUB_TINY disable MEMCG_KMEM, but that didn't happen so I left as is
for now.

> Thanks!

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ