Hello, Matt. cc'ing Roman and Alexei. On Tue, Mar 06, 2018 at 03:46:55PM -0800, Matt Roper wrote: > There are cases where other parts of the kernel may wish to store data > associated with individual cgroups without building a full cgroup > controller. Let's add interfaces to allow them to register and lookup > this private data for individual cgroups. > > A kernel system (e.g., a driver) that wishes to register private data > for a cgroup will do so by subclassing the 'struct cgroup_priv' > structure to describe the necessary data to store. Before registering a > private data structure to a cgroup, the caller should fill in the 'key' > and 'free' fields of the base cgroup_priv structure. > > * 'key' should be a unique void* that will act as a key for future > privdata lookups/removals. Note that this allows drivers to store > per-device private data for a cgroup by using a device pointer as a key. > > * 'free' should be a function pointer to a function that may be used > to destroy the private data. This function will be called > automatically if the underlying cgroup is destroyed. This feature turned out to have more users than I originally anticipated and bpf also wants something like this to track network states. The requirements are pretty similar but not quite the same. The extra requirements are... * Lookup must be really cheap. Probably using pointer hash or walking list isn't great, so maybe idr based lookup + RCU protected index table per cgroup? * It should support both regular memory and percpu pointers. Given that what cgroup does is pretty much cgroup:key -> pointer lookup, it's mostly about getting the interface right so that it's not too error-prone. Sorry about moving the goalpost. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
