linux-kernel - Re: [PATCH v3 3/3] mm/vmscan: don't demote if there is not enough free memory in the lower memory tier

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: <CAC5umyhoMi_J_Ford2M_1fB-qCuPEDopAK1OF=AisZyDZ8duJQ@mail.gmail.com>
Date: Sat, 10 Jan 2026 22:55:02 +0900
From: Akinobu Mita <akinobu.mita@...il.com>
To: gourry@...rry.net
Cc: linux-cxl@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-mm@...ck.org, akpm@...ux-foundation.org, axelrasmussen@...gle.com, 
	yuanchu@...gle.com, weixugc@...gle.com, hannes@...xchg.org, david@...nel.org, 
	mhocko@...nel.org, zhengqi.arch@...edance.com, shakeel.butt@...ux.dev, 
	lorenzo.stoakes@...cle.com, Liam.Howlett@...cle.com, vbabka@...e.cz, 
	rppt@...nel.org, surenb@...gle.com, bingjiao@...gle.com
Subject: Re: [PATCH v3 3/3] mm/vmscan: don't demote if there is not enough
 free memory in the lower memory tier

2026年1月10日(土) 1:08 Gregory Price <gourry@...rry.net>:
>
> > +     for_each_node_mask(nid, allowed_mask) {
> > +             int z;
> > +             struct zone *zone;
> > +             struct pglist_data *pgdat = NODE_DATA(nid);
> > +
> > +             for_each_managed_zone_pgdat(zone, pgdat, z, MAX_NR_ZONES - 1) {
> > +                     if (zone_watermark_ok(zone, 0, min_wmark_pages(zone),
> > +                                             ZONE_MOVABLE, 0))
>
> Why does this only check zone movable?

Here, zone_watermark_ok() checks the free memory for all zones from 0 to
MAX_NR_ZONES - 1.
There is no strong reason to pass ZONE_MOVABLE as the highest_zoneidx
argument every time zone_watermark_ok() is called; I can change it if an
appropriate value is found.
In v1, highest_zoneidx was "sc ? sc->reclaim_idx : MAX_NR_ZONES - 1"

> Also, would this also limit pressure-signal to invoke reclaim when
> there is still swap space available?  Should demotion not be a pressure
> source for triggering harder reclaim?

Since can_reclaim_anon_pages() checks whether there is free space on the swap
device before checking with can_demote(), I think the negative impact of this
change will be small. However, since I have not been able to confirm the
behavior when a swap device is available, I would like to correctly understand
the impact.