Re: [PATCH 03/13] mm: shmem: provide oom badness for shmem files

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

 



Am 13.06.22 um 11:08 schrieb Michel Dänzer:
On 2022-06-11 10:06, Christian König wrote:
Am 10.06.22 um 16:16 schrieb Michal Hocko:
[...]
Just consider the above mentioned memcg driven model. It doesn't really
require to chase specific files and do some arbitrary math to share the
responsibility. It has a clear accounting and responsibility model.
Ok, how does that work then?
The memory is accounted to whoever faults that memory in or to the
allocating context if that is a kernel memory (in most situations).
That's what I had in mind as well. Problem with this approach is that file descriptors are currently not informed that they are shared between processes.

So to make this work we would need something like attach/detach to process in struct file_operations.

And as I noted, this happens rather often. For example a game which renders 120 frames per second needs to transfer 120 buffers per second between client and X.
FWIW, in the steady state, the game will cycle between a small (generally 2-5) set of buffers. The game will not cause new buffers to be exported & imported for every frame.

In general, I'd expect dma-buf export & import to happen relatively rarely, e.g. when a window is opened or resized.

Yeah, on a normal Linux desktop. Just unfortunately not on Android :)

Anyway even when this only happens on game start we can't go over all the processes/fds and check where a DMA-buf is opened to account this against each process.

We would need to add callbacks for this to make it work halve way reliable.

Christian.



[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux