From: Boris Burkov <boris@bur.io>
To: Matthew Wilcox <willy@infradead.org>
Cc: akpm@linux-foundation.org, linux-btrfs@vger.kernel.org,
linux-mm@kvack.org, linux-fsdevel@vger.kernel.org,
kernel-team@fb.com, shakeel.butt@linux.dev, wqu@suse.com,
mhocko@kernel.org, muchun.song@linux.dev,
roman.gushchin@linux.dev, hannes@cmpxchg.org
Subject: Re: [PATCH v3 2/4] mm: add vmstat for cgroup uncharged pages
Date: Mon, 18 Aug 2025 21:05:10 -0700 [thread overview]
Message-ID: <20250819040510.GB740459@zen.localdomain> (raw)
In-Reply-To: <aKPmiWAwDPNdNBUA@casper.infradead.org>
On Tue, Aug 19, 2025 at 03:50:49AM +0100, Matthew Wilcox wrote:
> On Mon, Aug 18, 2025 at 05:36:54PM -0700, Boris Burkov wrote:
> > Uncharged pages are tricky to track by their essential "uncharged"
> > nature. To maintain good accounting, introduce a vmstat counter tracking
> > all uncharged pages. Since this is only meaningful when cgroups are
> > configured, only expose the counter when CONFIG_MEMCG is set.
>
> I don't understand why this is needed. Maybe Shakeel had better
> reasoning that wasn't captured in the commit message.
>
> If they're unaccounted, then you can get a good estimate of them
> just by subtracting the number of accounted pages from the number of
> file pages. Sure there's a small race between the two numbers being
> updated, so you migth be off by a bit.
I don't think there is any over the top elaborate reasoning beyond being
precise and accurate with stats being a good thing.
In my experience, implicit calculations like the one you propose tend to
lead to metrics that drift into incorrectness. Today's correct
calculation is tomorrow's wrong one, when the invariants from which it
was derived shift again. We have seen this in practice before with
kernel memory usage at Meta.
I don't think this costs a lot, and it has an easy to understand
definition. Are you concerned that there is only a single user in btrfs,
so that doesn't merit defining a new stat?
Sorry to put words in your mouth, just trying to guess what might be
objectionable about it.
Thanks for the reviews, by the way.
next prev parent reply other threads:[~2025-08-19 4:04 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-19 0:36 [PATCH v3 0/4] introduce uncharged file mapped folios Boris Burkov
2025-08-19 0:36 ` [PATCH v3 1/4] mm/filemap: add AS_UNCHARGED Boris Burkov
2025-08-19 2:46 ` Matthew Wilcox
2025-08-19 3:57 ` Boris Burkov
2025-08-20 22:06 ` Klara Modin
2025-08-20 22:22 ` Shakeel Butt
2025-08-20 22:52 ` Boris Burkov
2025-08-20 23:15 ` Klara Modin
2025-08-20 23:53 ` Shakeel Butt
2025-08-21 19:37 ` Shakeel Butt
2025-08-19 0:36 ` [PATCH v3 2/4] mm: add vmstat for cgroup uncharged pages Boris Burkov
2025-08-19 2:50 ` Matthew Wilcox
2025-08-19 4:05 ` Boris Burkov [this message]
2025-08-19 15:53 ` Shakeel Butt
2025-08-19 23:46 ` Matthew Wilcox
2025-08-20 1:25 ` Shakeel Butt
2025-08-20 13:19 ` Matthew Wilcox
2025-08-20 16:21 ` Shakeel Butt
2025-08-19 0:36 ` [PATCH v3 3/4] btrfs: set AS_UNCHARGED on the btree_inode Boris Burkov
2025-08-19 0:36 ` [PATCH v3 4/4] memcg: remove warning from folio_lruvec Boris Burkov
2025-08-19 2:41 ` Matthew Wilcox
2025-08-19 5:20 ` Andrew Morton
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=20250819040510.GB740459@zen.localdomain \
--to=boris@bur.io \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=kernel-team@fb.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=muchun.song@linux.dev \
--cc=roman.gushchin@linux.dev \
--cc=shakeel.butt@linux.dev \
--cc=willy@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox