From: Suren Baghdasaryan <surenb@google.com>
To: akpm@linux-foundation.org
Cc: willy@infradead.org, david@redhat.com, vbabka@suse.cz,
lorenzo.stoakes@oracle.com, liam.howlett@oracle.com,
alexandru.elisei@arm.com, peterx@redhat.com, hannes@cmpxchg.org,
mhocko@kernel.org, m.szyprowski@samsung.com,
iamjoonsoo.kim@lge.com, mina86@mina86.com, axboe@kernel.dk,
viro@zeniv.linux.org.uk, brauner@kernel.org, hch@infradead.org,
jack@suse.cz, hbathini@linux.ibm.com, sourabhjain@linux.ibm.com,
ritesh.list@gmail.com, aneesh.kumar@kernel.org,
bhelgaas@google.com, sj@kernel.org, fvdl@google.com,
ziy@nvidia.com, yuzhao@google.com, minchan@kernel.org,
surenb@google.com, linux-mm@kvack.org,
linuxppc-dev@lists.ozlabs.org, linux-block@vger.kernel.org,
linux-fsdevel@vger.kernel.org, iommu@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: [RFC 0/3] Guaranteed CMA
Date: Thu, 20 Mar 2025 10:39:28 -0700 [thread overview]
Message-ID: <20250320173931.1583800-1-surenb@google.com> (raw)
This RFC is posted to collect feedback and to be used as a reference
implementation for the upcoming LSF/MM discussion. The code is not of
production quality and needs more testing.
Guaranteed CMA (GCMA) is designed to improve utilization of reserved
memory carveouts without compromising their advantages of:
1. Guaranteed success of allocation (as long as total allocation size is
below the size of the reservation.
2. Low allocation latency.
The idea is that carved out memory when not used for its primary purpose
can be donated and used as an extension of the pagecache and any donated
page can be taken back at any moment with minimal latency and guaranteed
success.
To achieve this, GCMA needs to use memory that is not addressable by the
kernel (can't be pinned) and that contains content that can be discarded.
To provide such memory we reintroduce cleancache idea [1] with two major
changes. New implementation:
1. Avoids intrusive hooks into filesystem code, limiting them to two hooks
for filesystem mount/unmount events and a hook for bdev invalidation.
2. Manages fs->inode->page tracking and handles pools of donated pages
inside cleancache itself, freeing backends of this burden.
Cleancache provides a simple interface to its backends which lets them
donate a bunch of pages to cleancache, take a page back for own use and
return the page back to cleancache when not needed.
With cleancache in place, GCMA becomes a thin layer linking CMA allocator
to cleancache which allows existing CMA API to be used for continuous
memory allocations with additional guarantees listed above.
The limitation of GCMA is that its donated memory can be used only to
extend file-backed pagecache. Note that both CMA and GCMA can be used
at the same time.
The patchset borrows some ideas and code from previous implementations of
the cleancache and GCMA [2] as well as Android's reference patchset [3]
implemented by Minchan Kim and used by many Android vendors.
[1] https://elixir.bootlin.com/linux/v5.16.20/source/Documentation/vm/cleancache.rst
[2] https://lore.kernel.org/lkml/1424721263-25314-1-git-send-email-sj38.park@gmail.com/
[3] https://android-review.googlesource.com/q/topic:%22gcma_6.12%22
Minchan Kim (1):
mm: introduce GCMA
Suren Baghdasaryan (2):
mm: implement cleancache
mm: integrate GCMA with CMA using dt-bindings
arch/powerpc/kernel/fadump.c | 2 +-
block/bdev.c | 8 +
fs/super.c | 3 +
include/linux/cleancache.h | 88 ++++
include/linux/cma.h | 2 +-
include/linux/fs.h | 7 +
include/linux/gcma.h | 12 +
kernel/dma/contiguous.c | 11 +-
mm/Kconfig | 32 ++
mm/Makefile | 2 +
mm/cleancache.c | 926 +++++++++++++++++++++++++++++++++++
mm/cma.c | 33 +-
mm/cma.h | 1 +
mm/cma_sysfs.c | 10 +
mm/filemap.c | 63 ++-
mm/gcma.c | 155 ++++++
mm/truncate.c | 21 +-
17 files changed, 1356 insertions(+), 20 deletions(-)
create mode 100644 include/linux/cleancache.h
create mode 100644 include/linux/gcma.h
create mode 100644 mm/cleancache.c
create mode 100644 mm/gcma.c
base-commit: 40caf747267c18b6206e26a37d6ea6b695236c11
--
2.49.0.rc1.451.g8f38331e32-goog
next reply other threads:[~2025-03-20 17:39 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-20 17:39 Suren Baghdasaryan [this message]
2025-03-20 17:39 ` [RFC 1/3] mm: implement cleancache Suren Baghdasaryan
2025-03-21 5:13 ` Christoph Hellwig
2025-03-21 16:03 ` Suren Baghdasaryan
2025-03-20 17:39 ` [RFC 2/3] mm: introduce GCMA Suren Baghdasaryan
2025-03-21 5:14 ` Christoph Hellwig
2025-03-21 16:13 ` Suren Baghdasaryan
2025-03-20 17:39 ` [RFC 3/3] mm: integrate GCMA with CMA using dt-bindings Suren Baghdasaryan
2025-03-21 14:05 ` Conor Dooley
2025-03-21 16:14 ` Suren Baghdasaryan
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=20250320173931.1583800-1-surenb@google.com \
--to=surenb@google.com \
--cc=akpm@linux-foundation.org \
--cc=alexandru.elisei@arm.com \
--cc=aneesh.kumar@kernel.org \
--cc=axboe@kernel.dk \
--cc=bhelgaas@google.com \
--cc=brauner@kernel.org \
--cc=david@redhat.com \
--cc=fvdl@google.com \
--cc=hannes@cmpxchg.org \
--cc=hbathini@linux.ibm.com \
--cc=hch@infradead.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=iommu@lists.linux.dev \
--cc=jack@suse.cz \
--cc=liam.howlett@oracle.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=m.szyprowski@samsung.com \
--cc=mhocko@kernel.org \
--cc=mina86@mina86.com \
--cc=minchan@kernel.org \
--cc=peterx@redhat.com \
--cc=ritesh.list@gmail.com \
--cc=sj@kernel.org \
--cc=sourabhjain@linux.ibm.com \
--cc=vbabka@suse.cz \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@infradead.org \
--cc=yuzhao@google.com \
--cc=ziy@nvidia.com \
/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;
as well as URLs for NNTP newsgroup(s).