From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org, linux-mm@kvack.org,
linux-fsdevel@vger.kernel.org
Subject: [PATCH 0/2] mm: skip memcg for certain address space
Date: Wed, 10 Jul 2024 10:37:45 +0930 [thread overview]
Message-ID: <cover.1720572937.git.wqu@suse.com> (raw)
Recently I'm hitting soft lockup if adding an order 2 folio to a
filemap using GFP_NOFS | __GFP_NOFAIL. The softlockup happens at memcg
charge code, and I guess that's exactly what __GFP_NOFAIL is expected to
do, wait indefinitely until the request can be met.
On the other hand, if we do not use __GFP_NOFAIL, we can be limited by
memcg at a lot of critical location, and lead to unnecessary transaction
abort just due to memcg limit.
However for that specific btrfs call site, there is really no need charge
the memcg, as that address space belongs to btree inode, which is not
accessible to any end user, and that btree inode is a shared pool for
all metadata of a btrfs.
So this patchset introduces a new address space flag, AS_NO_MEMCG, so
that folios added to that address space will not trigger any memcg
charge.
This would be the basis for future btrfs changes, like removing
__GFP_NOFAIL completely and larger metadata folios.
Qu Wenruo (2):
mm: make lru_gen_eviction() to handle folios without memcg info
mm: allow certain address space to be not accounted by memcg
fs/btrfs/disk-io.c | 1 +
include/linux/pagemap.h | 1 +
mm/filemap.c | 12 +++++++++---
mm/workingset.c | 2 +-
4 files changed, 12 insertions(+), 4 deletions(-)
--
2.45.2
next 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 Qu Wenruo [this message]
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 ` [PATCH 2/2] mm: allow certain address space to be not accounted by memcg Qu Wenruo
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=cover.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;
as well as URLs for NNTP newsgroup(s).