linux-kernel - Re: [PATCH] mm, vmstat: remove the NR_WRITEBACK_TEMP node_stat

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <rr2hxi5dxoh6n4pbx5pcyelquvotbksfy2d2m5ycydafog65j4@rcekxluoecrr>
Date: Thu, 26 Jun 2025 09:00:44 +0200
From: Jan Kara <jack@...e.cz>
To: Joanne Koong <joannelkoong@...il.com>
Cc: Vlastimil Babka <vbabka@...e.cz>, 
	Andrew Morton <akpm@...ux-foundation.org>, "Matthew Wilcox (Oracle)" <willy@...radead.org>, 
	Tejun Heo <tj@...nel.org>, Maxim Patlasov <mpatlasov@...allels.com>, 
	Jan Kara <jack@...e.cz>, Zach O'Keefe <zokeefe@...gle.com>, 
	Jonathan Corbet <corbet@....net>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, 
	"Rafael J. Wysocki" <rafael@...nel.org>, Danilo Krummrich <dakr@...nel.org>, 
	Suren Baghdasaryan <surenb@...gle.com>, Michal Hocko <mhocko@...e.com>, 
	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>, Brendan Jackman <jackmanb@...gle.com>, 
	Johannes Weiner <hannes@...xchg.org>, Zi Yan <ziy@...dia.com>, Jingbo Xu <jefflexu@...ux.alibaba.com>, 
	Jeff Layton <jlayton@...nel.org>, Miklos Szeredi <mszeredi@...hat.com>, 
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org, linux-doc@...r.kernel.org, 
	linux-mm@...ck.org, Jens Axboe <axboe@...nel.dk>
Subject: Re: [PATCH] mm, vmstat: remove the NR_WRITEBACK_TEMP node_stat_item
 counter

On Wed 25-06-25 14:38:01, Joanne Koong wrote:
> On Wed, Jun 25, 2025 at 8:51 AM Vlastimil Babka <vbabka@...e.cz> wrote:
> >
> > The only user of the counter (FUSE) was removed in commit 0c58a97f919c
> > ("fuse: remove tmp folio for writebacks and internal rb tree") so follow
> > the established pattern of removing the counter and hardcoding 0 in
> > meminfo output, as done recently with NR_BOUNCE. Update documentation
> > for procfs, including for the value for Bounce that was missed when
> > removing its counter.
> >
> > Signed-off-by: Vlastimil Babka <vbabka@...e.cz>
> > ---
> > The removal of the counter is straightforward. The reason for the large
> > Cc list is that there is a comment in mm/page-writeback.c function
> > wb_position_ratio() that mentions NR_WRITEBACK_TEMP, and just deleting
> > the sentence feels to me it could be the wrong thing to do - maybe the
> > strictlimit feature itself is now obsolete? It sure does mention FUSE
> > as the main reason to exist, but commit 5a53748568f79 that introduced it
> > also mentions slow USB sticks as a possibile scenario. Has that
> > happened? I'm not familiar enough with this so I'd rather highlight this
> > and ask for input here than make "git grep NR_WRITEBACK_TEMP" return
> > nothing.
> 
> My understanding is that even without the fuse use case, strictlimit
> is still used for other devices via the /sys/class/bdi interface (eg
> /sys/class/bdi/<bdi>/strict_limit) so I don't think the feature itself
> is obsolete.
> 
> It's not clear to me whether fuse still needs strictlimit now that it
> doesn't have tmp writeback pages, but it'd be great to get an answer
> to this, as strictlimit currently leads to too much dirty throttling
> when large folios are enabled in fuse.

Well, Miklos would be the definitive source of truth here but as far as I
know strictlimit is still desirable for FUSE even without
NR_WRITEBACK_TEMP. Otherwise dirty pages in mappings where writeback can be
potentially very slow (and definitely under userspace control) could
consume most of the global dirty limit which is not what you usually want.
That being said I can definitely see there are usecases of FUSE mounts
where you don't want this extra throttling. But then it's upto sysadmin to
configure min/max_ratio properly in these cases to avoid excessive
throttling.

Regarding the comment, I'm frankly not certain how strictlimit solved
NR_WRITEBACK_TEMP issue because NR_WRITEBACK_TEMP was never included in any
computations there AFAICS. It just helped to limit amount of outstanding
dirty pages for FUSE mappings and thus indirectly limited the scope of
NR_WRITEBACK_TEMP issue. Anyway I think the sentence is obsolete now and
deleting it is indeed the right solution because FUSE writeback is now
properly accounted in the dirty limit.

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR