linux-kernel - Re: [PATCH] mm: vmscan: restore incremental cgroup iteration

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: <lgfq42xzqihzrz2hy32ktfdofhoub6pzvphjgwocpma55m5t3l@t6ckdxlk7wlw>
Date: Fri, 24 May 2024 18:35:16 +0200
From: Michal Koutný <mkoutny@...e.com>
To: Johannes Weiner <hannes@...xchg.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>, 
	Michal Hocko <mhocko@...nel.org>, Roman Gushchin <roman.gushchin@...ux.dev>, 
	Shakeel Butt <shakeel.butt@...ux.dev>, Rik van Riel <riel@...riel.com>, linux-mm@...ck.org, 
	cgroups@...r.kernel.org, linux-kernel@...r.kernel.org, kernel-team@...com
Subject: Re: [PATCH] mm: vmscan: restore incremental cgroup iteration

Hello.

On Tue, May 14, 2024 at 04:26:41PM GMT, Johannes Weiner <hannes@...xchg.org> wrote:
> The shared iterator state is maintaned inside the target cgroup, so
> fair and incremental walks are performed during both global reclaim
> and cgroup limit reclaim of complex subtrees.

Here it sounds like same fairness is maintained...

>  static void shrink_node_memcgs(pg_data_t *pgdat, struct scan_control *sc)
..
> +	 * persists across invocations. This strikes a balance between
> +	 * fairness and allocation latency.

..but here you write about balance between fairness and allocation.

IIUC, this spreads reclaim (of whole subtree) over longer time when more
events may affect the state of memory (e.g. more allocations), so
fairness would be "different". So the statement from code comment is
correct, right?

(I was also wondering how does this affect determinism of reclaim and
whether some chaotic or oscillatory patterns aren't possible but I guess
that needn't to be considered given it used to work before
1ba6fc9af35b.)

Thanks,
Michal

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)