On Fri, Jun 24, 2022 at 1:36 PM Daniel Vetter <daniel@xxxxxxxx> wrote: > > On Fri, Jun 24, 2022 at 01:32:45PM -0700, John Stultz wrote: > > On Fri, Jun 24, 2022 at 1:17 PM Daniel Vetter <daniel@xxxxxxxx> wrote: > > > > > > On Wed, Jun 15, 2022 at 10:31:21AM -0700, T.J. Mercier wrote: > > > > On Fri, May 20, 2022 at 9:25 AM T.J. Mercier <tjmercier@xxxxxxxxxx> wrote: > > > > > > > > > > On Fri, May 20, 2022 at 12:47 AM Tejun Heo <tj@xxxxxxxxxx> wrote: > > > > > > > > > > > > Hello, > > > > > > > > > > > > On Tue, May 17, 2022 at 04:30:29PM -0700, T.J. Mercier wrote: > > > > > > > Thanks for your suggestion. This almost works. "dmabuf" as a key could > > > > > > > work, but I'd actually like to account for each heap. Since heaps can > > > > > > > be dynamically added, I can't accommodate every potential heap name by > > > > > > > hardcoding registrations in the misc controller. > > > > > > > > > > > > On its own, that's a pretty weak reason to be adding a separate gpu > > > > > > controller especially given that it doesn't really seem to be one with > > > > > > proper abstractions for gpu resources. We don't want to keep adding random > > > > > > keys to misc controller but can definitely add limited flexibility. What > > > > > > kind of keys do you need? > > > > > > > > > > > Well the dmabuf-from-heaps component of this is the initial use case. > > > > > I was envisioning we'd have additional keys as discussed here: > > > > > https://lore.kernel.org/lkml/20220328035951.1817417-1-tjmercier@xxxxxxxxxx/T/#m82e5fe9d8674bb60160701e52dae4356fea2ddfa > > > > > So we'd end up with a well-defined core set of keys like "system", and > > > > > then drivers would be free to use their own keys for their own unique > > > > > purposes which could be complementary or orthogonal to the core set. > > > > > Yesterday I was talking with someone who is interested in limiting gpu > > > > > cores and bus IDs in addition to gpu memory. How to define core keys > > > > > is the part where it looks like there's trouble. > > > > > > > > > > For my use case it would be sufficient to have current and maximum > > > > > values for an arbitrary number of keys - one per heap. So the only > > > > > part missing from the misc controller (for my use case) is the ability > > > > > to register a new key at runtime as heaps are added. Instead of > > > > > keeping track of resources with enum misc_res_type, requesting a > > > > > resource handle/ID from the misc controller at runtime is what I think > > > > > would be required instead. > > > > > > > > > Quick update: I'm going to make an attempt to modify the misc > > > > controller to support a limited amount of dynamic resource > > > > registration/tracking in place of the new controller in this series. > > > > > > > > Thanks everyone for the feedback. > > > > > > Somehow I missed this entire chain here. > > > > > > I'm not a fan, because I'm kinda hoping we could finally unify gpu memory > > > account. Atm everyone just adds their one-off solution in a random corner: > > > - total tracking in misc cgroup controller > > > - dma-buf sysfs files (except apparently too slow so it'll get deleted > > > again) > > > - random other stuff on open device files os OOM killer can see it > > > > > > This doesn't look good. > > > > But I also think one could see it as "gpu memory" is the drm subsystem > > doing the same thing (in that it's artificially narrow to gpus). It > > seems we need something to account for buffers allocated by drivers, > > no matter which subsystem it was in (drm, v4l2, or networking or > > whatever). > > This is what the gpucg was. It wasn't called the dmabuf cg because we want > to account also memory of other types (e.g. drm gem buffer objects which > aren't exported), and I guess people didn't dare call it an xpu. > > But this was absolutely for a lot more than just "gpu drivers in drm". > Better names welcome. > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch >From an API perspective the two approaches (misc vs GPU) seem similar to me. Someone comes up with a name of a resource they want to track, and it's added as a key in a cgroup interface file as drivers register and perform accounting on that resource. Considering just the naming, what do you see as the appeal of a controller named GPU/XPU vs one named Misc? Folks seem to have assumptions about the type of resources a "GPU" controller should be tracking, and potentially also how different resources are grouped under a single resource name. So is your thought that non-graphics related accounting of the same sort should be using a differently named controller, even if that controller could have the same implementation? My thought is that the resource names should be as specific as possible to allow fine-grained accounting, and leave any grouping of resources to userspace. We can do that under any controller. If you'd like to see a separate controller for graphics related stuff... well that's what I was aiming for with the GPU cgroup controller. It's just that dmabufs from heaps are the first use-case wired up. I haven't put much time into the misc controller effort yet, and I'd still be happy to see the GPU controller accepted if we can agree about how it'd be used going forward. Daniel, I think you're in a great position to comment about this. :) If there's a place where the implementation is missing the mark, then let's change it. Are the controller and resource naming the only issues?
