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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJfpegtk9AEtj3kxivM=tm-DgSTnGqkv46HdNFcG34omJ2qVLw@mail.gmail.com>
Date: Mon, 30 Jun 2025 06:02:25 +0200
From: Miklos Szeredi <miklos@...redi.hu>
To: Jan Kara <jack@...e.cz>
Cc: Joanne Koong <joannelkoong@...il.com>, 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>, 
	"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 Thu, 26 Jun 2025 at 09:01, Jan Kara <jack@...e.cz> wrote:

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

The question is how much fuse can overrun the dirty limit without strictlimit.

AFAIU the strictlimit feature was added because temp pages were not
accounted as "dirty" as opposed to writeback pages which were.

Header of commit 5a53748568f7 ("mm/page-writeback.c: add strictlimit
feature") has more details.  But I don't fully understand all of that,
and strictlimit may still be useful.

Thanks,
Miklos