From: "Michel Dänzer" <michel.daenzer@mailbox.org>
To: "Christian König" <ckoenig.leichtzumerken@gmail.com>,
"Michal Hocko" <mhocko@suse.com>,
"Christian König" <christian.koenig@amd.com>
Cc: andrey.grodzovsky@amd.com, linux-mm@kvack.org,
nouveau@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
hughd@google.com, linux-kernel@vger.kernel.org,
amd-gfx@lists.freedesktop.org, linux-fsdevel@vger.kernel.org,
viro@zeniv.linux.org.uk, daniel@ffwll.ch,
linux-tegra@vger.kernel.org, alexander.deucher@amd.com,
akpm@linux-foundation.org, linux-media@vger.kernel.org
Subject: Re: [PATCH 03/13] mm: shmem: provide oom badness for shmem files
Date: Mon, 13 Jun 2022 11:08:52 +0200 [thread overview]
Message-ID: <51536e97-ca5f-abe4-b46c-ee3eb57f891e@mailbox.org> (raw)
In-Reply-To: <288528c3-411e-fb25-2f08-92d4bb9f1f13@gmail.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: "Michel Dänzer" <michel.daenzer@mailbox.org>
To: "Christian König" <ckoenig.leichtzumerken@gmail.com>,
"Michal Hocko" <mhocko@suse.com>,
"Christian König" <christian.koenig@amd.com>
Cc: andrey.grodzovsky@amd.com, linux-tegra@vger.kernel.org,
nouveau@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
hughd@google.com, linux-kernel@vger.kernel.org,
amd-gfx@lists.freedesktop.org, linux-mm@kvack.org,
viro@zeniv.linux.org.uk, daniel@ffwll.ch,
linux-fsdevel@vger.kernel.org, alexander.deucher@amd.com,
akpm@linux-foundation.org, linux-media@vger.kernel.org
Subject: Re: [PATCH 03/13] mm: shmem: provide oom badness for shmem files
Date: Mon, 13 Jun 2022 11:08:52 +0200 [thread overview]
Message-ID: <51536e97-ca5f-abe4-b46c-ee3eb57f891e@mailbox.org> (raw)
In-Reply-To: <288528c3-411e-fb25-2f08-92d4bb9f1f13@gmail.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: "Michel Dänzer" <michel.daenzer@mailbox.org>
To: "Christian König" <ckoenig.leichtzumerken@gmail.com>,
"Michal Hocko" <mhocko@suse.com>,
"Christian König" <christian.koenig@amd.com>
Cc: andrey.grodzovsky@amd.com, linux-tegra@vger.kernel.org,
nouveau@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
hughd@google.com, linux-kernel@vger.kernel.org,
amd-gfx@lists.freedesktop.org, linux-mm@kvack.org,
viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org,
alexander.deucher@amd.com, akpm@linux-foundation.org,
linux-media@vger.kernel.org
Subject: Re: [Intel-gfx] [PATCH 03/13] mm: shmem: provide oom badness for shmem files
Date: Mon, 13 Jun 2022 11:08:52 +0200 [thread overview]
Message-ID: <51536e97-ca5f-abe4-b46c-ee3eb57f891e@mailbox.org> (raw)
In-Reply-To: <288528c3-411e-fb25-2f08-92d4bb9f1f13@gmail.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: "Michel Dänzer" <michel.daenzer@mailbox.org>
To: "Christian König" <ckoenig.leichtzumerken@gmail.com>,
"Michal Hocko" <mhocko@suse.com>,
"Christian König" <christian.koenig@amd.com>
Cc: andrey.grodzovsky@amd.com, linux-tegra@vger.kernel.org,
nouveau@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
hughd@google.com, linux-kernel@vger.kernel.org,
amd-gfx@lists.freedesktop.org, linux-mm@kvack.org,
viro@zeniv.linux.org.uk, daniel@ffwll.ch,
linux-fsdevel@vger.kernel.org, alexander.deucher@amd.com,
akpm@linux-foundation.org, linux-media@vger.kernel.org
Subject: Re: [Nouveau] [PATCH 03/13] mm: shmem: provide oom badness for shmem files
Date: Mon, 13 Jun 2022 11:08:52 +0200 [thread overview]
Message-ID: <51536e97-ca5f-abe4-b46c-ee3eb57f891e@mailbox.org> (raw)
In-Reply-To: <288528c3-411e-fb25-2f08-92d4bb9f1f13@gmail.com>
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
next prev parent reply other threads:[~2022-06-13 9:14 UTC|newest]
Thread overview: 145+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-31 9:59 Per file OOM badness Christian König
2022-05-31 9:59 ` Christian König
2022-05-31 9:59 ` [Nouveau] " Christian König
2022-05-31 9:59 ` [PATCH 01/13] fs: add OOM badness callback to file_operatrations struct Christian König
2022-05-31 9:59 ` Christian König
2022-05-31 9:59 ` [Nouveau] " Christian König
2022-05-31 9:59 ` [PATCH 02/13] oom: take per file badness into account Christian König
2022-05-31 9:59 ` Christian König
2022-05-31 9:59 ` [Nouveau] " Christian König
2022-05-31 9:59 ` [PATCH 03/13] mm: shmem: provide oom badness for shmem files Christian König
2022-05-31 9:59 ` Christian König
2022-05-31 9:59 ` [Nouveau] " Christian König
2022-06-09 9:18 ` Michal Hocko
2022-06-09 9:18 ` [Nouveau] " Michal Hocko
2022-06-09 9:18 ` Michal Hocko
2022-06-09 9:18 ` [Intel-gfx] " Michal Hocko
2022-06-09 12:16 ` Christian König
2022-06-09 12:16 ` Christian König
2022-06-09 12:16 ` [Intel-gfx] " Christian König
2022-06-09 12:16 ` [Nouveau] " Christian König
2022-06-09 12:57 ` Michal Hocko
2022-06-09 12:57 ` [Nouveau] " Michal Hocko
2022-06-09 12:57 ` Michal Hocko
2022-06-09 12:57 ` [Intel-gfx] " Michal Hocko
2022-06-09 14:10 ` Christian König
2022-06-09 14:10 ` Christian König
2022-06-09 14:10 ` [Nouveau] " Christian König
2022-06-09 14:21 ` Michal Hocko
2022-06-09 14:21 ` [Nouveau] " Michal Hocko
2022-06-09 14:21 ` Michal Hocko
2022-06-09 14:21 ` [Intel-gfx] " Michal Hocko
2022-06-09 14:29 ` Christian König
2022-06-09 14:29 ` Christian König
2022-06-09 14:29 ` [Intel-gfx] " Christian König
2022-06-09 14:29 ` [Nouveau] " Christian König
2022-06-09 15:07 ` Michal Hocko
2022-06-09 15:07 ` [Nouveau] " Michal Hocko
2022-06-09 15:07 ` Michal Hocko
2022-06-09 15:07 ` [Intel-gfx] " Michal Hocko
2022-06-10 10:58 ` Christian König
2022-06-10 10:58 ` Christian König
2022-06-10 10:58 ` [Nouveau] " Christian König
2022-06-10 11:44 ` Michal Hocko
2022-06-10 11:44 ` [Nouveau] " Michal Hocko
2022-06-10 11:44 ` Michal Hocko
2022-06-10 11:44 ` [Intel-gfx] " Michal Hocko
2022-06-10 12:17 ` Christian König
2022-06-10 12:17 ` Christian König
2022-06-10 12:17 ` [Intel-gfx] " Christian König
2022-06-10 12:17 ` [Nouveau] " Christian König
2022-06-10 14:16 ` Michal Hocko
2022-06-10 14:16 ` [Nouveau] " Michal Hocko
2022-06-10 14:16 ` Michal Hocko
2022-06-10 14:16 ` [Intel-gfx] " Michal Hocko
2022-06-11 8:06 ` Christian König
2022-06-11 8:06 ` Christian König
2022-06-11 8:06 ` [Intel-gfx] " Christian König
2022-06-11 8:06 ` [Nouveau] " Christian König
2022-06-13 7:45 ` Michal Hocko
2022-06-13 7:45 ` [Nouveau] " Michal Hocko
2022-06-13 7:45 ` Michal Hocko
2022-06-13 7:45 ` [Intel-gfx] " Michal Hocko
2022-06-13 11:50 ` Christian König
2022-06-13 11:50 ` Christian König
2022-06-13 11:50 ` [Intel-gfx] " Christian König
2022-06-13 11:50 ` [Nouveau] " Christian König
2022-06-13 12:11 ` Michal Hocko
2022-06-13 12:11 ` [Nouveau] " Michal Hocko
2022-06-13 12:11 ` Michal Hocko
2022-06-13 12:11 ` [Intel-gfx] " Michal Hocko
2022-06-13 12:55 ` [Nouveau] " Christian König
2022-06-13 12:55 ` Christian König
2022-06-13 12:55 ` Christian König
2022-06-13 12:55 ` [Intel-gfx] " Christian König
2022-06-13 14:11 ` Michal Hocko
2022-06-13 14:11 ` [Nouveau] " Michal Hocko
2022-06-13 14:11 ` Michal Hocko
2022-06-13 14:11 ` Michal Hocko
2022-06-15 12:35 ` Christian König
2022-06-15 12:35 ` Christian König
2022-06-15 12:35 ` [Intel-gfx] " Christian König
2022-06-15 12:35 ` [Nouveau] " Christian König
2022-06-15 13:15 ` Michal Hocko
2022-06-15 13:15 ` [Nouveau] " Michal Hocko
2022-06-15 13:15 ` Michal Hocko
2022-06-15 13:15 ` [Intel-gfx] " Michal Hocko
2022-06-15 14:24 ` Christian König
2022-06-15 14:24 ` Christian König
2022-06-15 14:24 ` [Intel-gfx] " Christian König
2022-06-15 14:24 ` [Nouveau] " Christian König
2022-06-13 9:08 ` Michel Dänzer [this message]
2022-06-13 9:08 ` Michel Dänzer
2022-06-13 9:08 ` [Intel-gfx] " Michel Dänzer
2022-06-13 9:08 ` Michel Dänzer
2022-06-13 9:11 ` Christian König
2022-06-13 9:11 ` Christian König
2022-06-13 9:11 ` [Intel-gfx] " Christian König
2022-06-13 9:11 ` [Nouveau] " Christian König
2022-06-09 15:19 ` Felix Kuehling
2022-06-09 15:19 ` Felix Kuehling
2022-06-09 15:19 ` [Intel-gfx] " Felix Kuehling
2022-06-09 15:19 ` [Nouveau] " Felix Kuehling
2022-06-09 15:22 ` Christian König
2022-06-09 15:22 ` Christian König
2022-06-09 15:22 ` [Intel-gfx] " Christian König
2022-06-09 15:22 ` [Nouveau] " Christian König
2022-06-09 15:54 ` Michal Hocko
2022-06-09 15:54 ` [Nouveau] " Michal Hocko
2022-06-09 15:54 ` Michal Hocko
2022-06-09 15:54 ` [Intel-gfx] " Michal Hocko
2022-05-31 9:59 ` [PATCH 04/13] dma-buf: provide oom badness for DMA-buf files Christian König
2022-05-31 9:59 ` Christian König
2022-05-31 9:59 ` [Nouveau] " Christian König
2022-05-31 9:59 ` [PATCH 05/13] drm/gem: adjust per file OOM badness on handling buffers Christian König
2022-05-31 9:59 ` Christian König
2022-05-31 9:59 ` [Nouveau] " Christian König
2022-05-31 10:00 ` [PATCH 06/13] drm/gma500: use drm_oom_badness Christian König
2022-05-31 10:00 ` Christian König
2022-05-31 10:00 ` [Nouveau] " Christian König
2022-05-31 10:00 ` [PATCH 07/13] drm/amdgpu: Use drm_oom_badness for amdgpu Christian König
2022-05-31 10:00 ` Christian König
2022-05-31 10:00 ` [Nouveau] " Christian König
2022-05-31 10:00 ` [PATCH 08/13] drm/radeon: use drm_oom_badness Christian König
2022-05-31 10:00 ` Christian König
2022-05-31 10:00 ` [Nouveau] " Christian König
2022-05-31 10:00 ` [PATCH 09/13] drm/i915: " Christian König
2022-05-31 10:00 ` Christian König
2022-05-31 10:00 ` [Nouveau] " Christian König
2022-05-31 10:00 ` [PATCH 10/13] drm/nouveau: " Christian König
2022-05-31 10:00 ` Christian König
2022-05-31 10:00 ` [Nouveau] " Christian König
2022-05-31 10:00 ` [PATCH 11/13] drm/omap: " Christian König
2022-05-31 10:00 ` Christian König
2022-05-31 10:00 ` [Nouveau] " Christian König
2022-05-31 10:00 ` [PATCH 12/13] drm/vmwgfx: " Christian König
2022-05-31 10:00 ` Christian König
2022-05-31 10:00 ` [Nouveau] " Christian König
2022-05-31 10:00 ` [PATCH 13/13] drm/tegra: " Christian König
2022-05-31 10:00 ` Christian König
2022-05-31 10:00 ` [Nouveau] " Christian König
2022-05-31 22:00 ` Per file OOM badness Alex Deucher
2022-05-31 22:00 ` Alex Deucher
2022-05-31 22:00 ` [Intel-gfx] " Alex Deucher
2022-05-31 22:00 ` Alex Deucher
2022-05-31 22:00 ` [Nouveau] " Alex Deucher
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51536e97-ca5f-abe4-b46c-ee3eb57f891e@mailbox.org \
--to=michel.daenzer@mailbox.org \
--cc=akpm@linux-foundation.org \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=andrey.grodzovsky@amd.com \
--cc=christian.koenig@amd.com \
--cc=ckoenig.leichtzumerken@gmail.com \
--cc=daniel@ffwll.ch \
--cc=hughd@google.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-tegra@vger.kernel.org \
--cc=mhocko@suse.com \
--cc=nouveau@lists.freedesktop.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.