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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20241213-gentle-glittering-salamander-22addf@houat>
Date: Fri, 13 Dec 2024 16:21:00 +0100
From: Maxime Ripard <mripard@...nel.org>
To: Maarten Lankhorst <dev@...khorst.se>
Cc: linux-kernel@...r.kernel.org, intel-xe@...ts.freedesktop.org, 
	dri-devel@...ts.freedesktop.org, Tejun Heo <tj@...nel.org>, Zefan Li <lizefan.x@...edance.com>, 
	Johannes Weiner <hannes@...xchg.org>, Andrew Morton <akpm@...ux-foundation.org>, 
	Friedrich Vock <friedrich.vock@....de>, cgroups@...r.kernel.org, linux-mm@...ck.org, 
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>
Subject: Re: [PATCH v2 0/7] kernel/cgroups: Add "dmem" memory accounting
 cgroup.

On Fri, Dec 13, 2024 at 03:53:13PM +0100, Maarten Lankhorst wrote:
> 
> 
> Den 2024-12-13 kl. 14:03, skrev Maxime Ripard:
> > Hi,
> > 
> > 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.

Maxime

Download attachment "signature.asc" of type "application/pgp-signature" (274 bytes)