From: Matthew Wilcox <willy@infradead.org>
To: David Hildenbrand <david@redhat.com>
Cc: lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org
Subject: Re: [LSF/MM/BPF TOPIC] SLAB BOF
Date: Wed, 24 Apr 2024 15:43:02 +0100 [thread overview]
Message-ID: <ZikadnSrsYLerjEO@casper.infradead.org> (raw)
In-Reply-To: <bd204e8b-a7b3-4861-aa17-317d325a6505@redhat.com>
On Wed, Apr 24, 2024 at 02:52:41PM +0200, David Hildenbrand wrote:
> Just as a side note, I would be interested into something that can easily
> reclaim pages from slab in a specific physical memory area. Target use cases
> are around alloc_contig_range(), memory offlining an similar.
>
> ... but IIUC, the barn/sheep approach wouldn't make that any easier, right?
It'll make it harder, tbh, because today we track each object from its
struct slab. If we want to do something like this, we need to do a few
things:
- Send an IPI to all CPUs to let them know they need to return
their delayed-free sheaf immediately
- CPUs on the node which owns the memory we're trying to reclaim also
need to search their allocation sheaf for objects that we no longer
want to allocate
But I fear this is pointless. Unless we can get _all_ objects in the
range back, we may as well get none of them. Which means we need a
mechanism for asking the user of the kmem_cache to reallocate specific
objects. We've looked at something like that before, most recently:
https://lore.kernel.org/linux-mm/20190520054017.32299-11-tobin@kernel.org/
(you can forget about ever reclaiming from kmalloc slabs, but a real slab
cache could be movable)
prev parent reply other threads:[~2024-04-24 14:43 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-22 14:23 Matthew Wilcox
2024-04-24 12:52 ` David Hildenbrand
2024-04-24 14:43 ` Matthew Wilcox [this message]
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=ZikadnSrsYLerjEO@casper.infradead.org \
--to=willy@infradead.org \
--cc=david@redhat.com \
--cc=linux-mm@kvack.org \
--cc=lsf-pc@lists.linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox