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. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
