lkml.org 
[lkml]   [2022]   [Jun]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 03/13] mm: shmem: provide oom badness for shmem files
From
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.

\
 
 \ /
  Last update: 2022-06-13 11:12    [W:0.156 / U:0.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site