From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Cc: Michal Hocko <mhocko@suse.com>, Vlastimil Babka <vbabka@kernel.org>
Subject: [PATCH v5 1/2] btrfs: always uses root memcgroup for filemap_add_folio()
Date: Fri, 19 Jul 2024 14:19:05 +0930 [thread overview]
Message-ID: <d408a1b35307101e82a6845e26af4a122c8e5a25.1721363035.git.wqu@suse.com> (raw)
In-Reply-To: <cover.1721363035.git.wqu@suse.com>
The function filemap_add_folio() would also charge the memory cgroup,
as all filemap folios are controlled by memory cgroup.
This also means, if there is some memory cgroup set, we're only relying
on the __GFP_NOFAIL flag to prevent mem cgroup to return -ENOMEM.
However this is not really that suitable for btrfs btree inode, as the
btree inode is not accessible out of btrfs module, and we do not want
the memory limits on this critical part of btrfs metadata allocation.
So here we just manually set the active memory cgroup to the root one,
which has no memory limits or whatever, before calling
filemap_add_folio(), then restore to the old memcgroup.
By this we avoid the unnecessary memory limits and can later remove the
__GFP_NOFAIL usage.
Suggested-by: Michal Hocko <mhocko@suse.com>
Suggested-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
Signed-off-by: Qu Wenruo <wqu@suse.com>
---
fs/btrfs/extent_io.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index aa7f8148cd0d..cfeed7673009 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -2971,6 +2971,7 @@ static int attach_eb_folio_to_filemap(struct extent_buffer *eb, int i,
struct btrfs_fs_info *fs_info = eb->fs_info;
struct address_space *mapping = fs_info->btree_inode->i_mapping;
+ struct mem_cgroup *old_memcg;
const unsigned long index = eb->start >> PAGE_SHIFT;
struct folio *existing_folio = NULL;
int ret;
@@ -2981,8 +2982,17 @@ static int attach_eb_folio_to_filemap(struct extent_buffer *eb, int i,
ASSERT(eb->folios[i]);
retry:
+ /*
+ * Btree inode is a btrfs internal inode, and not exposed to any
+ * user.
+ * Furthermore we do not want any cgroup limits on this inode.
+ * So we always use root_mem_cgroup as our active memcg when attaching
+ * the folios.
+ */
+ old_memcg = set_active_memcg(root_mem_cgroup);
ret = filemap_add_folio(mapping, eb->folios[i], index + i,
GFP_NOFS | __GFP_NOFAIL);
+ set_active_memcg(old_memcg);
if (!ret)
goto finish;
--
2.45.2
next prev parent reply other threads:[~2024-07-19 4:49 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-19 4:49 [PATCH v5 0/2] btrfs: try to allocate larger folios for metadata Qu Wenruo
2024-07-19 4:49 ` Qu Wenruo [this message]
2024-07-19 7:08 ` [PATCH v5 1/2] btrfs: always uses root memcgroup for filemap_add_folio() Michal Hocko
2024-07-19 7:16 ` Qu Wenruo
2024-07-19 7:20 ` Qu Wenruo
2024-07-19 7:26 ` Michal Hocko
2024-07-19 15:42 ` kernel test robot
2024-07-19 15:42 ` kernel test robot
2024-07-19 4:49 ` [PATCH v5 2/2] btrfs: prefer to allocate larger folio for metadata Qu Wenruo
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=d408a1b35307101e82a6845e26af4a122c8e5a25.1721363035.git.wqu@suse.com \
--to=wqu@suse.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=mhocko@suse.com \
--cc=vbabka@kernel.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