linux-fsdevel.vger.kernel.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 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


             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).