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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <51536e97-ca5f-abe4-b46c-ee3eb57f891e@mailbox.org>
Date:   Mon, 13 Jun 2022 11:08:52 +0200
From:   Michel Dänzer <michel.daenzer@...lbox.org>
To:     Christian König <ckoenig.leichtzumerken@...il.com>,
        Michal Hocko <mhocko@...e.com>,
        Christian König <christian.koenig@....com>
Cc:     andrey.grodzovsky@....com, linux-mm@...ck.org,
        nouveau@...ts.freedesktop.org, intel-gfx@...ts.freedesktop.org,
        hughd@...gle.com, linux-kernel@...r.kernel.org,
        amd-gfx@...ts.freedesktop.org, linux-fsdevel@...r.kernel.org,
        viro@...iv.linux.org.uk, daniel@...ll.ch,
        linux-tegra@...r.kernel.org, alexander.deucher@....com,
        akpm@...ux-foundation.org, linux-media@...r.kernel.org
Subject: Re: [PATCH 03/13] mm: shmem: provide oom badness for shmem files

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.


-- 
Earthling Michel Dänzer            |                  https://redhat.com
Libre software enthusiast          |         Mesa and Xwayland developer