On Thu, Sep 5, 2019 at 4:32 PM Daniel Vetter daniel@ffwll.ch wrote:
*snip*
drm_dev_unregister gets called on hotunplug, so your cgroup-internal tracking won't get out of sync any more than the drm_minor list gets out of sync with drm_devices. The trouble with drm_minor is just that cgroup doesn't track allocations on drm_minor (that's just the uapi flavour), but on the underlying drm_device. So really doesn't make much sense to attach cgroup tracking to the drm_minor.
Um... I think I get what you are saying, but isn't this a matter of the cgroup controller doing a drm_dev_get when using the drm_minor? Or that won't work because it's possible to have a valid drm_minor but invalid drm_device in it? I understand it's an extra level of indirection but since the convention for addressing device in cgroup is using $major:$minor I don't see a way to escape this. (Tejun actually already made a comment on my earlier RFC where I didn't follow the major:minor convention strictly.)
Kenny
Just doing a drm_cg_register/unregister pair that's called from drm_dev_register/unregister, and then if you want, looking up the right minor (I think always picking the render node makes sense for this, and skipping if there's no render node) would make most sense. At least for the basic cgroup controllers which are generic across drivers.
Why do we want to skip drm devices that does not have a render node and not just use the primary instead?
I guess we could also take the primary node, but drivers with only primary node are generaly display-only drm drivers. Not sure we want cgroups on those (but I guess can't hurt, and more consistent). But then we'd always need to pick the primary node for cgroup identification purposes. -Daniel
Kenny
-Daniel