On 12/19/25 16:58, Maxime Ripard wrote:

On Fri, Dec 19, 2025 at 02:50:50PM +0100, Christian König wrote:

...

On 12/19/25 11:25, Maxime Ripard wrote:

...

On Mon, Dec 15, 2025 at 03:53:22PM +0100, Christian König wrote:

...

On 12/15/25 14:59, Maxime Ripard wrote:

...

...

...

...

...

> The shared ownership is indeed broken, but it's not more or less broken > than, say, memfd + udmabuf, and I'm sure plenty of others. > > So we really improve the common case, but only make the "advanced" > slightly more broken than it already is. > > Would you disagree?

I strongly disagree. As far as I can see there is a huge chance we break existing use cases with that.

Which ones? And what about the ones that are already broken?

Well everybody that expects that driver resources are *not* accounted to memcg.

Which is a thing only because these buffers have never been accounted for in the first place.

Yeah, completely agree. By not accounting it for such a long time we ended up with people depending on this behavior.

Not nice, but that's what it is.

...

So I guess the conclusion is that we shouldn't even try to do memory accounting, because someone somewhere might not expect that one of its application would take too much RAM in the system?

Well we do need some kind of solution to the problem. Either having some setting where you say "This memcg limit is inclusive/exclusive device driver allocated memory" or have a completely separate limit for device driver allocated memory.

A device driver memory specific limit sounds like a good idea because it would make it easier to bridge the gap with dmem.

Completely agree, but that approach was rejected by the cgroups people.

I mean we can already use udmabuf to allocate memcg accounted system memory which then can be imported into device drivers.

So I don't see much reason why we should account dma-buf heaps and driver interfaces to memcg as well, we just need some way to limit them.

Regards, Christian.

Happy holidays, Maxime