From: Boris Burkov <boris@bur.io>
To: linux-btrfs@vger.kernel.org, linux-mm@kvack.org,
linux-fsdevel@vger.kernel.org, kernel-team@fb.com
Cc: shakeel.butt@linux.dev, wqu@suse.com, willy@infradead.org
Subject: [PATCH v2 1/3] mm/filemap: add AS_UNCHARGED
Date: Fri, 15 Aug 2025 16:40:31 -0700 [thread overview]
Message-ID: <38448707b0dfb7fabae28cbebba3481eec6f2f4e.1755300815.git.boris@bur.io> (raw)
In-Reply-To: <cover.1755300815.git.boris@bur.io>
Btrfs currently tracks its metadata pages in the page cache, using a
fake inode (fs_info->btree_inode) with offsets corresponding to where
the metadata is stored in the filesystem's full logical address space.
A consequence of this is that when btrfs uses filemap_add_folio(), this
usage is charged to the cgroup of whichever task happens to be running
at the time. These folios don't belong to any particular user cgroup, so
I don't think it makes much sense for them to be charged in that way.
Some negative consequences as a result:
- A task can be holding some important btrfs locks, then need to lookup
some metadata and go into reclaim, extending the duration it holds
that lock for, and unfairly pushing its own reclaim pain onto other
cgroups.
- If that cgroup goes into reclaim, it might reclaim these folios a
different non-reclaiming cgroup might need soon. This is naturally
offset by LRU reclaim, but still.
A very similar proposal to use the root cgroup was previously made by
Qu, where he eventually proposed the idea of setting it per
address_space. This makes good sense for the btrfs use case, as the
uncharged behavior should apply to all use of the address_space, not
select allocations. I.e., if someone adds another filemap_add_folio()
call using btrfs's btree_inode, we would almost certainly want the
uncharged behavior.
Link: https://lore.kernel.org/linux-mm/b5fef5372ae454a7b6da4f2f75c427aeab6a07d6.1727498749.git.wqu@suse.com/
Suggested-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Boris Burkov <boris@bur.io>
---
include/linux/pagemap.h | 1 +
mm/filemap.c | 12 ++++++++----
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h
index 12a12dae727d..1ca63761a13a 100644
--- a/include/linux/pagemap.h
+++ b/include/linux/pagemap.h
@@ -211,6 +211,7 @@ enum mapping_flags {
folio contents */
AS_INACCESSIBLE = 8, /* Do not attempt direct R/W access to the mapping */
AS_WRITEBACK_MAY_DEADLOCK_ON_RECLAIM = 9,
+ AS_UNCHARGED = 10, /* Do not charge usage to a cgroup */
/* Bits 16-25 are used for FOLIO_ORDER */
AS_FOLIO_ORDER_BITS = 5,
AS_FOLIO_ORDER_MIN = 16,
diff --git a/mm/filemap.c b/mm/filemap.c
index 751838ef05e5..6046e7f27709 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -960,15 +960,19 @@ int filemap_add_folio(struct address_space *mapping, struct folio *folio,
{
void *shadow = NULL;
int ret;
+ bool charge_mem_cgroup = !test_bit(AS_UNCHARGED, &mapping->flags);
- ret = mem_cgroup_charge(folio, NULL, gfp);
- if (ret)
- return ret;
+ if (charge_mem_cgroup) {
+ ret = mem_cgroup_charge(folio, NULL, gfp);
+ if (ret)
+ return ret;
+ }
__folio_set_locked(folio);
ret = __filemap_add_folio(mapping, folio, index, gfp, &shadow);
if (unlikely(ret)) {
- mem_cgroup_uncharge(folio);
+ if (charge_mem_cgroup)
+ mem_cgroup_uncharge(folio);
__folio_clear_locked(folio);
} else {
/*
--
2.50.1
next prev parent reply other threads:[~2025-08-15 23:39 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-15 23:40 [PATCH v2 0/3] introduce uncharged file mapped folios Boris Burkov
2025-08-15 23:40 ` Boris Burkov [this message]
2025-08-16 0:41 ` [PATCH v2 1/3] mm/filemap: add AS_UNCHARGED Shakeel Butt
2025-08-15 23:40 ` [PATCH v2 2/3] mm: add vmstat for cgroup uncharged pages Boris Burkov
2025-08-16 0:48 ` Shakeel Butt
2025-08-16 0:54 ` Shakeel Butt
2025-08-15 23:40 ` [PATCH v2 3/3] btrfs: set AS_UNCHARGED on the btree_inode Boris Burkov
2025-08-16 0:50 ` Shakeel Butt
2025-08-16 12:52 ` David Sterba
2025-08-17 8:34 ` [syzbot ci] Re: introduce uncharged file mapped folios syzbot ci
2025-08-18 16:36 ` Shakeel Butt
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=38448707b0dfb7fabae28cbebba3481eec6f2f4e.1755300815.git.boris@bur.io \
--to=boris@bur.io \
--cc=kernel-team@fb.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=shakeel.butt@linux.dev \
--cc=willy@infradead.org \
--cc=wqu@suse.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