Hi Jarkko
On Wed, 13 Sep 2023 04:39:06 -0500, Jarkko Sakkinen <jarkko@xxxxxxxxxx>
wrote:
On Wed Sep 13, 2023 at 7:06 AM EEST, Haitao Huang wrote:
From: Kristen Carlson Accardi <kristen@xxxxxxxxxxxxxxx>
Consumers of the misc cgroup controller might need to perform separate
actions for Cgroups Subsystem State(CSS) events: cgroup alloc and free.
nit: s/State(CSS)/State (CSS)/
"cgroup alloc" and "cgroup free" mean absolutely nothing.
In addition, writes to the max value may also need separate action. Add
What "the max value"?
the ability to allow downstream users to setup callbacks for these
operations, and call the corresponding per-resource-type callback when
appropriate.
Who are "the downstream users" and what sort of callbacks they setup?
How about this?
The misc cgroup controller (subsystem) currently does not perform resource
type specific action for Cgroups Subsystem State (CSS) events: the
'css_alloc' event when a cgroup is created and the 'css_free' event when a
cgroup is destroyed, or in event of user writing the max value to the
misc.max file to set the consumption limit of a specific resource
[admin-guide/cgroup-v2.rst, 5-9. Misc].
Define callbacks for those events and allow resource providers to register
the callbacks per resource type as needed. This will be utilized later by
the EPC misc cgroup support implemented in the SGX driver:
- On cgroup alloc, allocate and initialize necessary structures for EPC
reclaiming, e.g., LRU list, work queue, etc.
- On cgroup free, cleanup and free those structures created in alloc.
- On max write, trigger EPC reclaiming if the new limit is at or below
current consumption.
Thanks
Haitao
