On Sat Sep 16, 2023 at 7:11 AM EEST, Haitao Huang wrote: > 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. Yeah, this is much better (I was on holiday, thus the delay on response). > Thanks > Haitao BR, Jarkko
