[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251114182130.1549832-1-mkoutny@suse.com>
Date: Fri, 14 Nov 2025 19:21:24 +0100
From: Michal Koutný <mkoutny@...e.com>
To: cgroups@...r.kernel.org,
linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org
Cc: Natalie Vock <natalie.vock@....de>,
Maarten Lankhorst <dev@...khorst.se>,
Michal Koutný <mkoutny@...e.com>,
Johannes Weiner <hannes@...xchg.org>,
Jonathan Corbet <corbet@....net>,
Tejun Heo <tj@...nel.org>
Subject: [PATCH v2 0/3] Memory reclaim documentation fixes
I think the reclaim target is a concept that is not just an
implementation detail and hence it should be documented how it applies
to protection configuration (the first patch). Second patch is a "best
practice" bit of information, it may be squashed with the first one. The
last patch just makes docs indefinite until the idea is implemented.
Originally sent in [1], this is rebased and resent since I still think
it'd be good to have the concept somewhere documented. (E.g. for the
guys who are implementing protection for the dmem controller [2] to
arrive at similar behavior.)
[1] https://lore.kernel.org/lkml/20200729140537.13345-1-mkoutny@suse.com/
[2] https://lore.kernel.org/r/20251110-dmemcg-aggressive-protect-v3-5-219ffcfc54e9@gmx.de
v2:
- diagram syntax (Jonathan)
v1 (https://lore.kernel.org/r/20251110193638.623208-1-mkoutny@suse.com/)
Michal Koutný (3):
docs: cgroup: Explain reclaim protection target
docs: cgroup: Note about sibling relative reclaim protection
docs: cgroup: No special handling of unpopulated memcgs
Documentation/admin-guide/cgroup-v2.rst | 31 ++++++++++++++++++++-----
1 file changed, 25 insertions(+), 6 deletions(-)
base-commit: 1c353dc8d962de652bc7ad2ba2e63f553331391c
--
2.51.1
Powered by blists - more mailing lists