linux-kernel - Re: [PATCH v5 2/2] mm: add swapiness= arg to memory.reclaim

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <ZZV66igbHQShq7-k@dschatzberg-fedora-PC0Y6AEN>
Date: Wed, 3 Jan 2024 10:19:06 -0500
From: Dan Schatzberg <schatzberg.dan@...il.com>
To: Yu Zhao <yuzhao@...gle.com>
Cc: Johannes Weiner <hannes@...xchg.org>,
	Roman Gushchin <roman.gushchin@...ux.dev>,
	Yosry Ahmed <yosryahmed@...gle.com>, Huan Yang <link@...o.com>,
	linux-kernel@...r.kernel.org, cgroups@...r.kernel.org,
	linux-mm@...ck.org, Tejun Heo <tj@...nel.org>,
	Zefan Li <lizefan.x@...edance.com>,
	Jonathan Corbet <corbet@....net>, Michal Hocko <mhocko@...nel.org>,
	Shakeel Butt <shakeelb@...gle.com>,
	Muchun Song <muchun.song@...ux.dev>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Kefeng Wang <wangkefeng.wang@...wei.com>,
	SeongJae Park <sj@...nel.org>,
	"Vishal Moola (Oracle)" <vishal.moola@...il.com>,
	Nhat Pham <nphamcs@...il.com>, Yue Zhao <findns94@...il.com>
Subject: Re: [PATCH v5 2/2] mm: add swapiness= arg to memory.reclaim

On Tue, Jan 02, 2024 at 05:27:18PM -0700, Yu Zhao wrote:
[...]
> > Helper aside, I disagree with this point about coupling with the
> > proactive flag.
> 
> Sure. But I would like to hear a *concrete* counterexample.
> 
> > The fact that the only user currently is proactive
> > reclaim
> 
> Yes, that's a fact, and we should make the decision based on the
> current known facts.
> 
> > doesn't imply to me that the interface (in scan_control)
> > should be coupled to the use-case.
> 
> Future always has its uncertainty which I would not worry so much about.
> 
> > It's easier to reason about a
> > swappiness field that overrides swappiness for all scans that set it
> > regardless of the users.
> 
> For example? And how likely would that happen in the next few years?

My argument isn't that making the interface more generic will be
worthwhile due to some future use-case. Rather my argument is that
making the interface more generic makes the code simpler. All else
being equal, having sc->swappiness behave the same regardless of
sc->proactive makes vmscan.c and struct scan_control easier to follow.

That being said - I'm fine with conceding this point - particularly
since both you and Michal appear to feel similarly. I'll make the
corresponding change and send out a new version.