Messages in this thread | | | Date | Mon, 13 Jun 2022 11:11:31 +0200 | Subject | Re: [PATCH 03/13] mm: shmem: provide oom badness for shmem files | From | Christian König <> |
| |
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.
| |