Received-SPF: pass (google.com: domain of linux-kernel+bounces-188936-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Fri, 24 May 2024 18:35:16 +0200
From: Michal =?utf-8?Q?Koutn=C3=BD?= <mkoutny@suse.com>
To: Johannes Weiner <hannes@cmpxchg.org>
Cc: Andrew Morton <akpm@linux-foundation.org>, 
	Michal Hocko <mhocko@kernel.org>, Roman Gushchin <roman.gushchin@linux.dev>, 
	Shakeel Butt <shakeel.butt@linux.dev>, Rik van Riel <riel@surriel.com>, linux-mm@kvack.org, 
	cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@fb.com
Subject: Re: [PATCH] mm: vmscan: restore incremental cgroup iteration
Message-ID: <lgfq42xzqihzrz2hy32ktfdofhoub6pzvphjgwocpma55m5t3l@t6ckdxlk7wlw>
References: <20240514202641.2821494-1-hannes@cmpxchg.org>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="k4bf6d4mqghjgxbc"
Content-Disposition: inline
In-Reply-To: <20240514202641.2821494-1-hannes@cmpxchg.org>


--k4bf6d4mqghjgxbc
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hello.

On Tue, May 14, 2024 at 04:26:41PM GMT, Johannes Weiner <hannes@cmpxchg.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

--k4bf6d4mqghjgxbc
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQQpEWyjXuwGT2dDBqAGvrMr/1gcjgUCZlDBwgAKCRAGvrMr/1gc
jhe/AQDeuUp02+73sDIL5zqyPUXNV1J4tLh52NWJ4CJkOBS7fgEA8xyeMuWDv/nm
f8A0QEu/w2m5znd1sLbI3LdmB+334Q4=
=7NM5
-----END PGP SIGNATURE-----

--k4bf6d4mqghjgxbc--