From: "Michal Koutný" <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
Date: Fri, 24 May 2024 18:35:16 +0200 [thread overview]
Message-ID: <lgfq42xzqihzrz2hy32ktfdofhoub6pzvphjgwocpma55m5t3l@t6ckdxlk7wlw> (raw)
In-Reply-To: <20240514202641.2821494-1-hannes@cmpxchg.org>
[-- Attachment #1: Type: text/plain, Size: 1050 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
prev parent reply other threads:[~2024-05-24 16:35 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-14 20:26 Johannes Weiner
2024-05-14 20:48 ` Shakeel Butt
2024-05-14 23:36 ` Roman Gushchin
2024-05-24 16:35 ` Michal Koutný [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=lgfq42xzqihzrz2hy32ktfdofhoub6pzvphjgwocpma55m5t3l@t6ckdxlk7wlw \
--to=mkoutny@suse.com \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=kernel-team@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=riel@surriel.com \
--cc=roman.gushchin@linux.dev \
--cc=shakeel.butt@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox