linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org, linux-mm@kvack.org,
	linux-fsdevel@vger.kernel.org
Subject: [PATCH 2/2] mm: allow certain address space to be not accounted by memcg
Date: Wed, 10 Jul 2024 10:37:47 +0930	[thread overview]
Message-ID: <92dea37a395781ee4d5cf8b16307801ccd8a5700.1720572937.git.wqu@suse.com> (raw)
In-Reply-To: <cover.1720572937.git.wqu@suse.com>

Currently any page/folio added to an address space will be accounted by
memcg.

However this is not always true for certain address spaces.
One example is the address space of btrfs btree inode, which stores the
metadata of one btrfs.

Currently btrfs is using __GFP_NOFAIL for all operations touching that
address space, but this can has other problems as __GFP_NOFAIL can wait
infinitely until the request is met.

To avoid unnecessary memcg charge for the btree inode address space,
introduce a new flag, AS_NO_MEMCG, to inform that folios added to that
address space should not trigger memcg charge/uncharge, and add btrfs
btree inode to utilize that new flag.

Signed-off-by: Qu Wenruo <wqu@suse.com>
---
 fs/btrfs/disk-io.c      |  1 +
 include/linux/pagemap.h |  1 +
 mm/filemap.c            | 12 +++++++++---
 3 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index 9e64e9fde832..2de9db95fbb9 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -1931,6 +1931,7 @@ static int btrfs_init_btree_inode(struct super_block *sb)
 	inode->i_size = OFFSET_MAX;
 	inode->i_mapping->a_ops = &btree_aops;
 	mapping_set_gfp_mask(inode->i_mapping, GFP_NOFS);
+	set_bit(AS_NO_MEMCG, &inode->i_mapping->flags);
 
 	extent_io_tree_init(fs_info, &BTRFS_I(inode)->io_tree,
 			    IO_TREE_BTREE_INODE_IO);
diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h
index 59f1df0cde5a..d4634d5d5dab 100644
--- a/include/linux/pagemap.h
+++ b/include/linux/pagemap.h
@@ -209,6 +209,7 @@ enum mapping_flags {
 	AS_STABLE_WRITES,	/* must wait for writeback before modifying
 				   folio contents */
 	AS_UNMOVABLE,		/* The mapping cannot be moved, ever */
+	AS_NO_MEMCG,		/* No memcg should be applied to this address space .*/
 };
 
 /**
diff --git a/mm/filemap.c b/mm/filemap.c
index 876cc64aadd7..a2282aa4f2a6 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -960,11 +960,17 @@ int filemap_add_folio(struct address_space *mapping, struct folio *folio,
 				pgoff_t index, gfp_t gfp)
 {
 	void *shadow = NULL;
+	const bool no_memcg = test_bit(AS_NO_MEMCG, &mapping->flags);
 	int ret;
 
-	ret = mem_cgroup_charge(folio, NULL, gfp);
-	if (ret)
-		return ret;
+	if (!no_memcg) {
+		ret = mem_cgroup_charge(folio, NULL, gfp);
+		if (ret)
+			return ret;
+	} else {
+		/* The page should not has any memcg set for it. */
+		VM_BUG_ON_FOLIO(folio_memcg(folio), folio);
+	}
 
 	__folio_set_locked(folio);
 	ret = __filemap_add_folio(mapping, folio, index, gfp, &shadow);
-- 
2.45.2



  parent reply	other threads:[~2024-07-10  1:08 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-10  1:07 [PATCH 0/2] mm: skip memcg for certain address space Qu Wenruo
2024-07-10  1:07 ` [PATCH 1/2] mm: make lru_gen_eviction() to handle folios without memcg info Qu Wenruo
2024-07-10  1:07 ` Qu Wenruo [this message]
2024-07-17  7:42 ` [PATCH 0/2] mm: skip memcg for certain address space Qu Wenruo
2024-07-17 15:55 ` Vlastimil Babka (SUSE)
2024-07-17 16:14   ` Michal Hocko
2024-07-17 22:38     ` Qu Wenruo
2024-07-18  7:17       ` Vlastimil Babka (SUSE)
2024-07-18  7:25         ` Michal Hocko
2024-07-18  7:57           ` Qu Wenruo
2024-07-18  8:09             ` Michal Hocko
2024-07-18  8:10               ` Michal Hocko
2024-07-18  8:52               ` Qu Wenruo
2024-07-18  9:25                 ` Michal Hocko
2024-07-18  7:52         ` Qu Wenruo
2024-07-18  8:28           ` Vlastimil Babka (SUSE)
2024-07-18  8:50             ` Qu Wenruo
2024-07-18  9:19               ` Vlastimil Babka (SUSE)
2024-07-25  9:00   ` 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=92dea37a395781ee4d5cf8b16307801ccd8a5700.1720572937.git.wqu@suse.com \
    --to=wqu@suse.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.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