Hello, On Tue, Nov 20, 2018 at 10:21:14PM +0000, Ho, Kenny wrote: > By this reply, are you suggesting that vendor specific resources > will never be acceptable to be managed under cgroup? Let say a user I wouldn't say never but whatever which gets included as a cgroup controller should have clearly defined resource abstractions and the control schemes around them including support for delegation. AFAICS, gpu side still seems to have a long way to go (and it's not clear whether that's somewhere it will or needs to end up). > want to have similar functionality as what cgroup is offering but to > manage vendor specific resources, what would you suggest as a > solution? When you say keeping vendor specific resource regulation > inside drm or specific drivers, do you mean we should replicate the > cgroup infrastructure there or do you mean either drm or specific > driver should query existing hierarchy (such as device or perhaps > cpu) for the process organization information? > > To put the questions in more concrete terms, let say a user wants to > expose certain part of a gpu to a particular cgroup similar to the > way selective cpu cores are exposed to a cgroup via cpuset, how > should we go about enabling such functionality? Do what the intel driver or bpf is doing? It's not difficult to hook into cgroup for identification purposes. Thanks. -- tejun _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
