On 5/6/2019 8:26 AM, Tejun Heo wrote: > Hello, > > On Wed, May 01, 2019 at 10:04:33AM -0400, Brian Welty wrote: >> The patch series enables device drivers to use cgroups to control the >> following resources within a GPU (or other accelerator device): >> * control allocation of device memory (reuse of memcg) >> and with future work, we could extend to: >> * track and control share of GPU time (reuse of cpu/cpuacct) >> * apply mask of allowed execution engines (reuse of cpusets) >> >> Instead of introducing a new cgroup subsystem for GPU devices, a new >> framework is proposed to allow devices to register with existing cgroup >> controllers, which creates per-device cgroup_subsys_state within the >> cgroup. This gives device drivers their own private cgroup controls >> (such as memory limits or other parameters) to be applied to device >> resources instead of host system resources. >> Device drivers (GPU or other) are then able to reuse the existing cgroup >> controls, instead of inventing similar ones. > > I'm really skeptical about this approach. When creating resource > controllers, I think what's the most important and challenging is > establishing resource model - what resources are and how they can be > distributed. This patchset is going the other way around - building > out core infrastructure for bolierplates at a significant risk of > mixing up resource models across different types of resources. > > IO controllers already implement per-device controls. I'd suggest > following the same interface conventions and implementing a dedicated > controller for the subsystem. > Okay, thanks for feedback. Preference is clear to see this done as dedicated cgroup controller. Part of my proposal was an attempt for devices with "mem like" and "cpu like" attributes to be managed by common controller. We can ignore this idea for cpu attributes, as those can just go in a GPU controller. There might still be merit in having a 'device mem' cgroup controller. The resource model at least is then no longer mixed up with host memory. RDMA community seemed to have some interest in a common controller at least for device memory aspects. Thoughts on this? I believe could still reuse the 'struct mem_cgroup' data structure. There should be some opportunity to reuse charging APIs and have some nice integration with HMM for charging to device memory, depending on backing store. -Brian _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
