Thread (96 messages) 96 messages, 9 authors, 2024-03-12

Re: [PATCH v4 03/36] mm/slub: Mark slab_free_freelist_hook() __always_inline

From: Suren Baghdasaryan <surenb@google.com>
Date: 2024-02-24 02:02:36
Also in: cgroups, linux-arch, linux-doc, linux-fsdevel, linux-iommu, linux-mm, lkml

On Wed, Feb 21, 2024 at 1:16 PM Pasha Tatashin
[off-list ref] wrote:
On Wed, Feb 21, 2024 at 2:41 PM Suren Baghdasaryan [off-list ref] wrote:
quoted
From: Kent Overstreet <kent.overstreet@linux.dev>

It seems we need to be more forceful with the compiler on this one.
This is done for performance reasons only.

Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Reviewed-by: Kees Cook <redacted>
---
 mm/slub.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/slub.c b/mm/slub.c
index 2ef88bbf56a3..d31b03a8d9d5 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -2121,7 +2121,7 @@ bool slab_free_hook(struct kmem_cache *s, void *x, bool init)
        return !kasan_slab_free(s, x, init);
 }

-static inline bool slab_free_freelist_hook(struct kmem_cache *s,
+static __always_inline bool slab_free_freelist_hook(struct kmem_cache *s,
__fastpath_inline seems to me more appropriate here. It prioritizes
memory vs performance.
Hmm. AFAIKT this function is used only in one place and we do not add
any additional users, so I don't think changing to __fastpath_inline
here would gain us anything.
quoted
                                           void **head, void **tail,
                                           int *cnt)
 {
--
2.44.0.rc0.258.g7320e95886-goog
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help