* [RFC] dmisc cgroups controller
@ 2026-08-14 9:32 Thomas Hellström
2026-08-16 19:10 ` Tejun Heo
0 siblings, 1 reply; 3+ messages in thread
From: Thomas Hellström @ 2026-08-14 9:32 UTC (permalink / raw)
To: Tejun Heo, maarten.lankhorst; +Cc: intel-xe, cgroups, dri-devel, pallavi.mishra
Hi!
We (drm/xe GPU driver) have a use-case where we have a very limited
number of a particular device resource (CLOS slots) that we potentially
want to expose to unprivlieged processes for reservation / allocation.
We want to be able to restrict per cgroups the number of CLOS slots
that are available for reservation / allocation.
This is not a good fit for the misc controller since these resource
types may be added and removed similar to dmem regions. Neither is it a
good fit for the dmem controller.
Would a dmisc controller be suitable here? It would be similar to the
misc countroller but with dynamic addition and removal of resource
types similar to the dmem controller.
Any input greatly appreciated.
Thanks,
Thomas
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [RFC] dmisc cgroups controller
2026-08-14 9:32 [RFC] dmisc cgroups controller Thomas Hellström
@ 2026-08-16 19:10 ` Tejun Heo
2026-08-18 9:51 ` Thomas Hellström
0 siblings, 1 reply; 3+ messages in thread
From: Tejun Heo @ 2026-08-16 19:10 UTC (permalink / raw)
To: Thomas Hellström
Cc: maarten.lankhorst, intel-xe, cgroups, dri-devel, pallavi.mishra
On Fri, Aug 14, 2026 at 11:32:54AM +0200, Thomas Hellström wrote:
> Hi!
>
> We (drm/xe GPU driver) have a use-case where we have a very limited
> number of a particular device resource (CLOS slots) that we potentially
> want to expose to unprivlieged processes for reservation / allocation.
> We want to be able to restrict per cgroups the number of CLOS slots
> that are available for reservation / allocation.
>
> This is not a good fit for the misc controller since these resource
> types may be added and removed similar to dmem regions. Neither is it a
> good fit for the dmem controller.
>
> Would a dmisc controller be suitable here? It would be similar to the
> misc countroller but with dynamic addition and removal of resource
> types similar to the dmem controller.
>
> Any input greatly appreciated.
Would extending the existing misc controller be an option?
Thanks.
--
tejun
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [RFC] dmisc cgroups controller
2026-08-16 19:10 ` Tejun Heo
@ 2026-08-18 9:51 ` Thomas Hellström
0 siblings, 0 replies; 3+ messages in thread
From: Thomas Hellström @ 2026-08-18 9:51 UTC (permalink / raw)
To: Tejun Heo; +Cc: maarten.lankhorst, intel-xe, cgroups, dri-devel, pallavi.mishra
On Sun, 2026-08-16 at 09:10 -1000, Tejun Heo wrote:
> On Fri, Aug 14, 2026 at 11:32:54AM +0200, Thomas Hellström wrote:
> > Hi!
> >
> > We (drm/xe GPU driver) have a use-case where we have a very limited
> > number of a particular device resource (CLOS slots) that we
> > potentially
> > want to expose to unprivlieged processes for reservation /
> > allocation.
> > We want to be able to restrict per cgroups the number of CLOS slots
> > that are available for reservation / allocation.
> >
> > This is not a good fit for the misc controller since these resource
> > types may be added and removed similar to dmem regions. Neither is
> > it a
> > good fit for the dmem controller.
> >
> > Would a dmisc controller be suitable here? It would be similar to
> > the
> > misc countroller but with dynamic addition and removal of resource
> > types similar to the dmem controller.
> >
> > Any input greatly appreciated.
>
> Would extending the existing misc controller be an option?
Certainly. I think a main concern though would be testing of the
existing use-cases. But anyway I'll take a look in that direction.
Thanks,
Thomas
>
> Thanks.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-08-18 9:52 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-08-14 9:32 [RFC] dmisc cgroups controller Thomas Hellström
2026-08-16 19:10 ` Tejun Heo
2026-08-18 9:51 ` Thomas Hellström
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.