From: Michal Hocko <mhocko@suse.com>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>, Qu Wenruo <wqu@suse.com>,
linux-btrfs@vger.kernel.org, roman.gushchin@linux.dev,
shakeel.butt@linux.dev, muchun.song@linux.dev,
cgroups@vger.kernel.org, linux-mm@kvack.org,
Vlastimil Babka <vbabka@kernel.org>
Subject: Re: [PATCH v7 2/3] btrfs: always uses root memcgroup for filemap_add_folio()
Date: Mon, 22 Jul 2024 09:34:53 +0200 [thread overview]
Message-ID: <Zp4LnZS3MSqzM08J@tiehlicka> (raw)
In-Reply-To: <9202429f-e933-4212-a513-e065ba02517a@gmx.com>
On Sat 20-07-24 07:41:19, Qu Wenruo wrote:
[...]
> So according to the trend, I'm pretty sure VFS people will reject such
> new interface just to skip accounting.
I would just give it a try with your usecase described. If this is a
nogo then the root cgroup workaround is still available.
> Thus the GFP_NO_ACCOUNT solution looks more feasible.
So we have GFP_ACCOUNT to opt in for accounting and now we should be
adding GFP_NO_ACCOUNT to override it? This doesn't sound like a good use
of gfp flags (which we do not have infinitely) and it is also quite
confusing TBH.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2024-07-22 7:34 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-19 10:28 [PATCH v7 0/3] btrfs: try to allocate larger folios for metadata Qu Wenruo
2024-07-19 10:28 ` [PATCH v7 1/3] memcontrol: define root_mem_cgroup for CONFIG_MEMCG=n cases Qu Wenruo
2024-07-19 11:13 ` Michal Hocko
2024-07-19 21:58 ` Qu Wenruo
2024-07-22 7:32 ` Michal Hocko
2024-07-19 10:28 ` [PATCH v7 2/3] btrfs: always uses root memcgroup for filemap_add_folio() Qu Wenruo
2024-07-19 17:02 ` Johannes Weiner
2024-07-19 17:25 ` Roman Gushchin
2024-07-19 18:13 ` Michal Hocko
2024-07-19 22:11 ` Qu Wenruo
2024-07-22 7:34 ` Michal Hocko [this message]
2024-07-22 8:08 ` Qu Wenruo
2024-07-24 3:46 ` Qu Wenruo
2024-07-19 10:28 ` [PATCH v7 3/3] 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=Zp4LnZS3MSqzM08J@tiehlicka \
--to=mhocko@suse.com \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=muchun.song@linux.dev \
--cc=quwenruo.btrfs@gmx.com \
--cc=roman.gushchin@linux.dev \
--cc=shakeel.butt@linux.dev \
--cc=vbabka@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.