All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org,
	linux-mm@kvack.org, linux-block@vger.kernel.org,
	bpf@vger.kernel.org, linux-xfs@vger.kernel.org,
	David Rientjes <rientjes@google.com>,
	Christoph Lameter <cl@linux.com>,
	Pekka Enberg <penberg@kernel.org>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Hyeonggon Yoo <42.hyeyoo@gmail.com>,
	Roman Gushchin <roman.gushchin@linux.dev>
Subject: Re: [LSF/MM/BPF TOPIC] SLOB+SLAB allocators removal and future SLUB improvements
Date: Tue, 14 Mar 2023 13:06:38 +0000	[thread overview]
Message-ID: <ZBBxXhvL/oS3uu5/@casper.infradead.org> (raw)
In-Reply-To: <4b9fc9c6-b48c-198f-5f80-811a44737e5f@suse.cz>

On Tue, Mar 14, 2023 at 09:05:13AM +0100, Vlastimil Babka wrote:
> The immediate benefit of that is that we can allow kfree() (and kfree_rcu())
> to free objects from kmem_cache_alloc() - something that IIRC at least xfs
> people wanted in the past, and SLOB was incompatible with that.
> 
> For SLAB removal I haven't yet heard any objections (but also didn't
> deprecate it yet) but if there are any users due to particular workloads
> doing better with SLAB than SLUB, we can discuss why those would regress and
> what can be done about that in SLUB.
> 
> Once we have just one slab allocator in the kernel, we can take a closer
> look at what the users are missing from it that forces them to create own
> allocators (e.g. BPF), and could be considered to be added as a generic
> implementation to SLUB.

With kfree() now working on kmem_cache_alloc(), I'd like to re-propose
the introduction of a generic free() function which can free any
allocated object.  It starts out looking a lot like kvfree(), but
can be enhanced to cover other things ... here's a version I did from
2018 before giving up on it when I realised slob made it impossible:

+/**
+ * free() - Free memory
+ * @ptr: Pointer to memory
+ *
+ * This function can free almost any type of memory.  It can safely be
+ * called on:
+ * * NULL pointers.
+ * * Pointers to read-only data (will do nothing).
+ * * Pointers to memory allocated from kmalloc().
+ * * Pointers to memory allocated from kmem_cache_alloc().
+ * * Pointers to memory allocated from vmalloc().
+ * * Pointers to memory allocated from alloc_percpu().
+ * * Pointers to memory allocated from __get_free_pages().
+ * * Pointers to memory allocated from page_frag_alloc().
+ *
+ * It cannot free memory allocated by dma_pool_alloc() or dma_alloc_coherent().
+ */
+void free(const void *ptr)
+{
+       struct page *page;
+
+       if (unlikely(ZERO_OR_NULL_PTR(ptr)))
+               return;
+       if (is_kernel_rodata((unsigned long)ptr))
+               return;
+
+       page = virt_to_head_page(ptr);
+       if (likely(PageSlab(page)))
+               return kmem_cache_free(page->slab_cache, (void *)ptr);
+
+       if (is_vmalloc_addr(ptr))
+               return vfree(ptr);
+       if (is_kernel_percpu_address((unsigned long)ptr))
+               free_percpu((void __percpu *)ptr);
+       if (put_page_testzero(page))
+               __put_page(page);
+}
+EXPORT_SYMBOL(free);

Looking at it now, I'd also include a test for stack memory (and do
nothing if it is)

There are some prep patches that I'm not including here to clear out
the use of 'free' as a function name (some conflicting identifiers named
'free') and a fun one to set a SLAB_PAGE_DTOR on compound pages.

  reply	other threads:[~2023-03-14 13:26 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-14  8:05 [LSF/MM/BPF TOPIC] SLOB+SLAB allocators removal and future SLUB improvements Vlastimil Babka
2023-03-14 13:06 ` Matthew Wilcox [this message]
2023-03-15  2:54 ` Roman Gushchin
2023-03-16  8:18   ` Vlastimil Babka
2023-03-16 20:20     ` Roman Gushchin
2023-03-22 12:15 ` Binder Makin
2023-03-22 13:02   ` Hyeonggon Yoo
2023-03-22 13:24     ` Binder Makin
2023-03-22 13:30     ` Binder Makin
2023-03-22 12:30 ` Binder Makin
2023-04-04 16:03   ` Vlastimil Babka
2023-04-05 19:54     ` Binder Makin
2023-04-27  8:29       ` Vlastimil Babka
2023-05-05 19:44         ` Binder Makin

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=ZBBxXhvL/oS3uu5/@casper.infradead.org \
    --to=willy@infradead.org \
    --cc=42.hyeyoo@gmail.com \
    --cc=bpf@vger.kernel.org \
    --cc=cl@linux.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=lsf-pc@lists.linux-foundation.org \
    --cc=penberg@kernel.org \
    --cc=rientjes@google.com \
    --cc=roman.gushchin@linux.dev \
    --cc=vbabka@suse.cz \
    /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.