From: SeongJae Park <sj@kernel.org>
To: Suren Baghdasaryan <surenb@google.com>
Cc: SeongJae Park <sj@kernel.org>,
akpm@linux-foundation.org, david@redhat.com,
lorenzo.stoakes@oracle.com, Liam.Howlett@oracle.com,
vbabka@suse.cz, alexandru.elisei@arm.com, peterx@redhat.com,
rppt@kernel.org, mhocko@suse.com, corbet@lwn.net,
axboe@kernel.dk, viro@zeniv.linux.org.uk, brauner@kernel.org,
hch@infradead.org, jack@suse.cz, willy@infradead.org,
m.szyprowski@samsung.com, robin.murphy@arm.com,
hannes@cmpxchg.org, zhengqi.arch@bytedance.com,
shakeel.butt@linux.dev, axelrasmussen@google.com,
yuanchu@google.com, weixugc@google.com, minchan@kernel.org,
linux-mm@kvack.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-block@vger.kernel.org,
linux-fsdevel@vger.kernel.org, iommu@lists.linux.dev
Subject: Re: [PATCH 6/8] add cleancache documentation
Date: Fri, 10 Oct 2025 13:20:34 -0700 [thread overview]
Message-ID: <20251010202034.58002-1-sj@kernel.org> (raw)
In-Reply-To: <20251010011951.2136980-7-surenb@google.com>
Hello Suren,
On Thu, 9 Oct 2025 18:19:49 -0700 Suren Baghdasaryan <surenb@google.com> wrote:
> Document cleancache, it's APIs and sysfs interface.
>
> Signed-off-by: Suren Baghdasaryan <surenb@google.com>
> ---
> Documentation/mm/cleancache.rst | 112 ++++++++++++++++++++++++++++++++
> MAINTAINERS | 1 +
I think this great document is better to be linked on mm/index.rst.
Also, would it make sense to split the sysfs interface part and put under
Documentation/admin-guide/mm/ ?
> 2 files changed, 113 insertions(+)
> create mode 100644 Documentation/mm/cleancache.rst
>
> diff --git a/Documentation/mm/cleancache.rst b/Documentation/mm/cleancache.rst
> new file mode 100644
> index 000000000000..deaf7de51829
> --- /dev/null
> +++ b/Documentation/mm/cleancache.rst
> @@ -0,0 +1,112 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +==========
> +Cleancache
> +==========
> +
> +Motivation
> +==========
> +
> +Cleancache is a feature to utilize unused reserved memory for extending
> +page cache.
> +
> +Cleancache can be thought of as a folio-granularity victim cache for clean
> +file-backed pages that the kernel's pageframe replacement algorithm (PFRA)
> +would like to keep around, but can't since there isn't enough memory. So
> +when the PFRA "evicts" a folio, it stores the data contained in the folio
> +into cleancache memory which is not directly accessible or addressable by
> +the kernel (transcendent memory) and is of unknown and possibly
> +time-varying size.
IMHO, "(transcendent memory)" better to be dropped, as it has removed by commit
814bbf49dcd0 ("xen: remove tmem driver").
> +
> +Later, when a filesystem wishes to access a folio in a file on disk, it
> +first checks cleancache to see if it already contains required data; if it
> +does, the folio data is copied into the kernel and a disk access is
> +avoided.
> +
> +The memory cleancache uses is donated by other system components, which
> +reserve memory not directly addressable by the kernel. By donating this
> +memory to cleancache, the memory owner enables its utilization while it
> +is not used. Memory donation is done using cleancache backend API and any
> +donated memory can be taken back at any time by its donor without no delay
"without delay" or "with no delay" ?
> +and with guarantees success. Since cleancache uses this memory only to
> +store clean file-backed data, it can be dropped at any time and therefore
> +the donor's request to take back the memory can be always satisfied.
> +
> +Implementation Overview
> +=======================
> +
> +Cleancache "backend" (donor that provides transcendent memory), registers
Again, "transcendent memory" part seems better to be dropped.
> +itself with cleancache "frontend" and received a unique pool_id which it
> +can use in all later API calls to identify the pool of folios it donates.
> +Once registered, backend can call cleancache_backend_put_folio() or
> +cleancache_backend_put_folios() to donate memory to cleancache. Note that
> +cleancache currently supports only 0-order folios and will not accept
> +larger-order ones. Once the backend needs that memory back, it can get it
> +by calling cleancache_backend_get_folio(). Only the original backend can
> +take the folio it donated from the cleancache.
> +
> +Kernel uses cleancache by first calling cleancache_add_fs() to register
> +each file system and then using a combination of cleancache_store_folio(),
> +cleancache_restore_folio(), cleancache_invalidate_{folio|inode} to store,
> +restore and invalidate folio content.
> +cleancache_{start|end}_inode_walk() are used to walk over folios inside
> +an inode and cleancache_restore_from_inode() is used to restore folios
> +during such walks.
> +
> +From kernel's point of view folios which are copied into cleancache have
> +an indefinite lifetime which is completely unknowable by the kernel and so
> +may or may not still be in cleancache at any later time. Thus, as its name
> +implies, cleancache is not suitable for dirty folios. Cleancache has
> +complete discretion over what folios to preserve and what folios to discard
> +and when.
> +
> +Cleancache Performance Metrics
> +==============================
> +
> +If CONFIG_CLEANCACHE_SYSFS is enabled, monitoring of cleancache performance
> +can be done via sysfs in the `/sys/kernel/mm/cleancache` directory.
> +The effectiveness of cleancache can be measured (across all filesystems)
> +with provided stats.
> +Global stats are published directly under `/sys/kernel/mm/cleancache` and
> +include:
``/sys/kernel/mm/cleancache`` ?
> +
> +``stored``
> + number of successful cleancache folio stores.
> +
> +``skipped``
> + number of folios skipped during cleancache store operation.
> +
> +``restored``
> + number of successful cleancache folio restore operations.
> +
> +``missed``
> + number of failed cleancache folio restore operations.
> +
> +``reclaimed``
> + number of folios reclaimed from the cleancache due to insufficient
> + memory.
> +
> +``recalled``
> + number of times cleancache folio content was discarded as a result
> + of the cleancache backend taking the folio back.
> +
> +``invalidated``
> + number of times cleancache folio content was discarded as a result
> + of invalidation.
> +
> +``cached``
> + number of folios currently cached in the cleancache.
> +
> +Per-pool stats are published under `/sys/kernel/mm/cleancache/<pool name>`
``/sys/kernel/mm/cleancache/<pool name>`` ?
> +where "pool name" is the name pool was registered under. These stats
> +include:
> +
> +``size``
> + number of folios donated to this pool.
> +
> +``cached``
> + number of folios currently cached in the pool.
> +
> +``recalled``
> + number of times cleancache folio content was discarded as a result
> + of the cleancache backend taking the folio back from the pool.
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1c97227e7ffa..441e68c94177 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6053,6 +6053,7 @@ CLEANCACHE
> M: Suren Baghdasaryan <surenb@google.com>
> L: linux-mm@kvack.org
> S: Maintained
> +F: Documentation/mm/cleancache.rst
> F: include/linux/cleancache.h
> F: mm/cleancache.c
> F: mm/cleancache_sysfs.c
> --
> 2.51.0.740.g6adb054d12-goog
Thanks,
SJ
next prev parent reply other threads:[~2025-10-10 20:20 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-10 1:19 [PATCH 0/8] Guaranteed CMA Suren Baghdasaryan
2025-10-10 1:19 ` [PATCH 1/8] mm: implement cleancache Suren Baghdasaryan
2025-10-10 1:31 ` Andrew Morton
2025-10-10 1:42 ` Suren Baghdasaryan
2025-10-10 2:39 ` Matthew Wilcox
2025-10-10 14:53 ` Suren Baghdasaryan
2025-10-10 21:17 ` kernel test robot
2025-10-10 21:42 ` Suren Baghdasaryan
2025-10-13 6:44 ` Christoph Hellwig
2025-10-13 15:43 ` Suren Baghdasaryan
2025-10-10 1:19 ` [PATCH 2/8] mm/cleancache: add cleancache LRU for folio aging Suren Baghdasaryan
2025-10-10 1:19 ` [PATCH 3/8] mm/cleancache: readahead support Suren Baghdasaryan
2025-10-10 1:19 ` [PATCH 4/8] mm/cleancache: add sysfs interface Suren Baghdasaryan
2025-10-10 1:19 ` [PATCH 5/8] mm/tests: add cleancache kunit test Suren Baghdasaryan
2025-10-11 2:57 ` kernel test robot
2025-10-11 21:47 ` Suren Baghdasaryan
2025-10-10 1:19 ` [PATCH 6/8] add cleancache documentation Suren Baghdasaryan
2025-10-10 20:20 ` SeongJae Park [this message]
2025-10-10 22:09 ` Suren Baghdasaryan
2025-10-10 1:19 ` [PATCH 7/8] mm: introduce GCMA Suren Baghdasaryan
2025-10-10 21:11 ` SeongJae Park
2025-10-10 22:05 ` Suren Baghdasaryan
2025-10-10 1:19 ` [PATCH 8/8] mm: integrate GCMA with CMA using dt-bindings 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=20251010202034.58002-1-sj@kernel.org \
--to=sj@kernel.org \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=alexandru.elisei@arm.com \
--cc=axboe@kernel.dk \
--cc=axelrasmussen@google.com \
--cc=brauner@kernel.org \
--cc=corbet@lwn.net \
--cc=david@redhat.com \
--cc=hannes@cmpxchg.org \
--cc=hch@infradead.org \
--cc=iommu@lists.linux.dev \
--cc=jack@suse.cz \
--cc=linux-block@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=m.szyprowski@samsung.com \
--cc=mhocko@suse.com \
--cc=minchan@kernel.org \
--cc=peterx@redhat.com \
--cc=robin.murphy@arm.com \
--cc=rppt@kernel.org \
--cc=shakeel.butt@linux.dev \
--cc=surenb@google.com \
--cc=vbabka@suse.cz \
--cc=viro@zeniv.linux.org.uk \
--cc=weixugc@google.com \
--cc=willy@infradead.org \
--cc=yuanchu@google.com \
--cc=zhengqi.arch@bytedance.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 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.