Received-SPF: pass (google.com: domain of linux-kernel+bounces-60-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Date: Thu, 14 Dec 2023 12:14:40 -0800 (PST)
From: "Christoph Lameter (Ampere)" <cl@linux.com>
To: Matthew Wilcox <willy@infradead.org>
cc: Vlastimil Babka <vbabka@suse.cz>, Pekka Enberg <penberg@kernel.org>, 
    David Rientjes <rientjes@google.com>, Joonsoo Kim <iamjoonsoo.kim@lge.com>, 
    "Liam R. Howlett" <Liam.Howlett@oracle.com>, 
    Andrew Morton <akpm@linux-foundation.org>, 
    Roman Gushchin <roman.gushchin@linux.dev>, 
    Hyeonggon Yoo <42.hyeyoo@gmail.com>, 
    Alexander Potapenko <glider@google.com>, Marco Elver <elver@google.com>, 
    Dmitry Vyukov <dvyukov@google.com>, linux-mm@kvack.org, 
    linux-kernel@vger.kernel.org, maple-tree@lists.infradead.org, 
    kasan-dev@googlegroups.com
Subject: Re: [PATCH RFC v3 0/9] SLUB percpu array caches and maple tree
 nodes
In-Reply-To: <ZWerDCdvVkAfsStz@casper.infradead.org>
Message-ID: <146558f5-9f5c-e65f-0177-5f736fe663cd@linux.com>
References: <20231129-slub-percpu-caches-v3-0-6bcf536772bc@suse.cz> <b51bfc04-d770-3385-736a-01aa733c4622@linux.com> <ZWerDCdvVkAfsStz@casper.infradead.org>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed

On Wed, 29 Nov 2023, Matthew Wilcox wrote:

>> In order to make the SLUB in page freelists work better you need to have
>> larger freelist and that comes with larger page sizes. I.e. boot with
>> slub_min_order=5 or so to increase performance.
>
> That comes with its own problems, of course.

Well I thought you were solving those with the folios?

>> Also this means increasing TLB pressure. The in page freelists of SLUB cause
>> objects from the same page be served. The SLAB queueing approach
>> results in objects being mixed from any address and thus neighboring objects
>> may require more TLB entries.
>
> Is that still a concern for modern CPUs?  We're using 1GB TLB entries
> these days, and there are usually thousands of TLB entries.  This feels
> like more of a concern for a 90s era CPU.

ARM kernel memory is mapped by 4K entries by default since rodata=full is 
the default. Security concerns screw it up.