Hey,
Den 2024-12-13 kl. 14:07, skrev Maxime Ripard:
On Sun, Dec 08, 2024 at 01:15:34PM +0100, Friedrich Vock wrote:
Hi,
On 04.12.24 14:44, Maarten Lankhorst wrote:
Because it only deals with memory regions, the UAPI has been updated
to use dmem.min/low/max/current, and to make the API cleaner, the
names are changed too.
dmem.current could contain a line like:
"drm/0000:03:00.0/vram0 1073741824"
But I think using "drm/card0/vram0" instead of PCIID would perhaps
be good too. I'm open to changing it to that based on feedback.
Agree, allowing userspace to reference DRM devices via "cardN" syntax
sounds good.
What about other subsystems potentially using dmem cgroups?
I'm not familiar with the media subsystem, but I imagine we might be
dealing with things like USB devices there? Is something like a
"deviceN" possible there as well, or would device IDs look completely
different?
I'd just take what makes sense for each driver. dev_name() would be a
good approximation.
I agree that cardN is not stable.
> I have some patches to enable the cgroup in GEM-based drivers, media
ones and dma-buf heaps. The dma-buf heaps are simple enough since the
heaps names are supposed to be stable.
I've used your patch as a base enable cgroup in drivers that use the
VRAM manager. I didn't want to enable it for all of GEM, because it
would conflict with drivers using TTM. Some more discussion is needed first.
For DMA-BUF heaps, I think it's fine and there is a lot less need of
discussion. I just felt it should be sent separately from the initial
enablement.
I don't think using card0 vs card1 (or v4l0 vs v4l1 for example) will
work because I don't think we have any sort of guarantee that these
names will always point to the same devices across reboots or updates.
If the module is loaded later than it used to for example, we could very
well end up in a situation where card0 and card1 are swapped, while the
constraints apply to the previous situation.
I agree, just put it out there for discussion. I don't think the
benefits weigh up against the downsides :-)
Cheers,
~Maarten
