Re: [PATCH v2 0/7] kernel/cgroups: Add "dmem" memory accounting cgroup.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hey,

Now that all patches look good, what is needed to merge the series? Without patch 6/7 as it is a hack for testing.

I've also posted a IGT for verifying read/write works (rule out copy/paste errors) and min, max semantics work as intended.

https://lists.freedesktop.org/archives/igt-dev/2024-December/083345.html

Cheers,
~Maarten


Den 2024-12-17 kl. 08:46, skrev Maxime Ripard:
On Fri, Dec 13, 2024 at 05:06:05PM +0100, Maarten Lankhorst wrote:
Hey,

Den 2024-12-13 kl. 16:21, skrev Maxime Ripard:
On Fri, Dec 13, 2024 at 03:53:13PM +0100, Maarten Lankhorst wrote:


Den 2024-12-13 kl. 14:03, skrev Maxime Ripard:
Hi,l

Thanks for the new update!

On Wed, Dec 04, 2024 at 02:44:00PM +0100, Maarten Lankhorst wrote:
New update. Instead of calling it the 'dev' cgroup, it's now the
'dmem' cgroup.

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.

The API is much nicer, and fits much better into other frameworks 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.

Do we have any sort of guarantee over the name card0 being stable across
reboots?

I also wonder if we should have a "total" device that limits the amount
of memory we can allocate from any region?

I don't think it is useful. Say your app can use 1 GB of main memory or 2 GB
of VRAM, it wouldn't make sense to limit the total of those. In a lot of
cases there is only 1 region, so the total of that would still be the same.

On top, we just separated the management of each region, adding a 'total'
would require unseparating it again. :-)

I didn't mean the total for a device, but for the system. It would
definitely not make sense for a VRAM, but for CMA for example, you have
a single, limited, allocator that will be accessible from heaps, v4l2
and DRM devices.

If an application has to allocate both from v4l2 and DRM buffers, we
should be able to limit its total usage of CMA, not just on a single
device.

In this case, I think it makes more sense if CMA creates a region, then use
that region in both v4l2 and DRM instead of a separate region for both, with
CMA being responsible for lifetime.

Ack, thanks for your feedback :)

Maxime





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux