[PATCH 17/17] amdgpu: add support for memory cgroups

[Christian König]

On 03.07.25 23:22, David Airlie wrote:
>>
>> Do you mean a task in cgroup A does amdgpu_gem_object_create() and then
>> the actual allocation can happen in the task in cgroup B?
> 
> On android and in some graphics scenarios, this might happen, not sure
> if it does always though. We have scenarios where a display server
> allocate a buffer for an application to write into and then it
> displays it, the ownership of that buffer can be a big rough.

Yeah those use cases exists but are rather uncommon.

Also please keep in mind that Android has it's completely own way of memory management. It would be great if we could unify that with cgroups in the future as well, but that is not the task at hand.

> But in most scenarios I think it'll be the same cgroup, and I think we
> generally should account it to the original cgroup unless we
> explicitly move the object to another one, (which we haven't got any
> code for yet).

We just need to make sure that we don't create the possibility for a deny of service.

For example something we clearly can't do is client creates a buffer but doesn't touch it in any way, and then server receives the buffer and is forced into an OOM situation because it is the first one who's touching it.

>>>
>>> BTW: It might be a good idea to not only limit the amount of memory you actually have allocated, but also how much you wanted to allocate.
>>
>> Do you mean accounting and limiting the reservations? Something like
>> what hugetlb cgroup provides?

Yes, exactly that. Basically a limit on how much a process can over-commit those buffers.

Regards,
Christian.

>>
> 
> I'll let Christian answer that,
> Dave.
>