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
Date: Thu, 14 Dec 2023 12:14:40 -0800 (PST) [thread overview]
Message-ID: <146558f5-9f5c-e65f-0177-5f736fe663cd@linux.com> (raw)
In-Reply-To: <ZWerDCdvVkAfsStz@casper.infradead.org>
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.
next prev parent reply other threads:[~2023-12-14 20:14 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-29 9:53 [PATCH RFC v3 0/9] SLUB percpu array caches and maple tree nodes Vlastimil Babka
2023-11-29 9:53 ` [PATCH RFC v3 1/9] mm/slub: fix bulk alloc and free stats Vlastimil Babka
2023-11-29 9:53 ` [PATCH RFC v3 2/9] mm/slub: introduce __kmem_cache_free_bulk() without free hooks Vlastimil Babka
2023-11-29 9:53 ` [PATCH RFC v3 3/9] mm/slub: handle bulk and single object freeing separately Vlastimil Babka
2023-11-29 9:53 ` [PATCH RFC v3 4/9] mm/slub: free KFENCE objects in slab_free_hook() Vlastimil Babka
2023-11-29 12:00 ` Marco Elver
2023-11-29 9:53 ` [PATCH RFC v3 5/9] mm/slub: add opt-in percpu array cache of objects Vlastimil Babka
2023-11-29 10:35 ` Marco Elver
2023-12-15 18:28 ` Suren Baghdasaryan
2023-12-15 21:17 ` Suren Baghdasaryan
2023-11-29 9:53 ` [PATCH RFC v3 6/9] tools: Add SLUB percpu array functions for testing Vlastimil Babka
2023-11-29 9:53 ` [PATCH RFC v3 7/9] maple_tree: use slub percpu array Vlastimil Babka
2023-11-29 9:53 ` [PATCH RFC v3 8/9] maple_tree: Remove MA_STATE_PREALLOC Vlastimil Babka
2023-11-29 9:53 ` [PATCH RFC v3 9/9] maple_tree: replace preallocation with slub percpu array prefill Vlastimil Babka
2023-11-29 20:16 ` [PATCH RFC v3 0/9] SLUB percpu array caches and maple tree nodes Christoph Lameter (Ampere)
2023-11-29 21:20 ` Matthew Wilcox
2023-12-14 20:14 ` Christoph Lameter (Ampere) [this message]
2023-11-30 9:14 ` Vlastimil Babka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=146558f5-9f5c-e65f-0177-5f736fe663cd@linux.com \
--to=cl@linux.com \
--cc=42.hyeyoo@gmail.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=dvyukov@google.com \
--cc=elver@google.com \
--cc=glider@google.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=kasan-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=maple-tree@lists.infradead.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=vbabka@suse.cz \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.