Thread (208 messages) flat view 208 messages, 21 authors, 2024-02-29

Re: [PATCH v3 21/35] mm/slab: add allocation accounting into slab allocation and free paths

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

On Fri, Feb 16, 2024 at 8:39 AM Kent Overstreet
[off-list ref] wrote:
On Fri, Feb 16, 2024 at 05:31:11PM +0100, Vlastimil Babka wrote:
quoted
On 2/12/24 22:39, Suren Baghdasaryan wrote:
quoted
Account slab allocations using codetag reference embedded into slabobj_ext.

Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Co-developed-by: Kent Overstreet <kent.overstreet@linux.dev>
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
---
 mm/slab.h | 26 ++++++++++++++++++++++++++
 mm/slub.c |  5 +++++
 2 files changed, 31 insertions(+)
diff --git a/mm/slab.h b/mm/slab.h
index 224a4b2305fb..c4bd0d5348cb 100644
--- a/mm/slab.h
+++ b/mm/slab.h
@@ -629,6 +629,32 @@ prepare_slab_obj_exts_hook(struct kmem_cache *s, gfp_t flags, void *p)

 #endif /* CONFIG_SLAB_OBJ_EXT */

+#ifdef CONFIG_MEM_ALLOC_PROFILING
+
+static inline void alloc_tagging_slab_free_hook(struct kmem_cache *s, struct slab *slab,
+                                   void **p, int objects)
+{
+   struct slabobj_ext *obj_exts;
+   int i;
+
+   obj_exts = slab_obj_exts(slab);
+   if (!obj_exts)
+           return;
+
+   for (i = 0; i < objects; i++) {
+           unsigned int off = obj_to_index(s, slab, p[i]);
+
+           alloc_tag_sub(&obj_exts[off].ref, s->size);
+   }
+}
+
+#else
+
+static inline void alloc_tagging_slab_free_hook(struct kmem_cache *s, struct slab *slab,
+                                   void **p, int objects) {}
+
+#endif /* CONFIG_MEM_ALLOC_PROFILING */
You don't actually use the alloc_tagging_slab_free_hook() anywhere? I see
it's in the next patch, but logically should belong to this one.
I don't think it makes any sense to quibble about introducing something
in one patch that's not used until the next patch; often times, it's
just easier to review that way.
Yeah, there were several cases where I was debating with myself which
way to split a patch (same was, as you noticed, with
prepare_slab_obj_exts_hook()). Since we already moved
prepare_slab_obj_exts_hook(), alloc_tagging_slab_free_hook() will
probably move into the same patch. I'll go over the results once more
to see if the new split makes more sense, if not will keep it here.
Thanks!
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help