From: "Christian König" <christian.koenig@amd.com>
To: "Michal Hocko" <mhocko@suse.com>,
"Christian König" <ckoenig.leichtzumerken@gmail.com>
Cc: linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
intel-gfx@lists.freedesktop.org, amd-gfx@lists.freedesktop.org,
nouveau@lists.freedesktop.org, linux-tegra@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
alexander.deucher@amd.com, daniel@ffwll.ch,
viro@zeniv.linux.org.uk, akpm@linux-foundation.org,
hughd@google.com, andrey.grodzovsky@amd.com
Subject: Re: [PATCH 03/13] mm: shmem: provide oom badness for shmem files
Date: Wed, 15 Jun 2022 14:35:22 +0200 [thread overview]
Message-ID: <9e170201-35df-cfcc-8d07-2f9693278829@amd.com> (raw)
In-Reply-To: <YqdFkfLVFUD5K6EK@dhcp22.suse.cz>
Am 13.06.22 um 16:11 schrieb Michal Hocko:
> [SNIP]
>> Let me maybe get back to the initial question: We have resources which are
>> not related to the virtual address space of a process, how should we tell
>> the OOM killer about them?
> I would say memcg, but we have discussed this already...
Well memcg is at least closer to the requirements than the classic
mm_struct accounting.
It won't work for really shared buffers, but if that's the requirement
to find some doable solution for the remaining 99% then I can live with
that.
> I do not think that exposing a resource (in a form of a counter
> or something like that) is sufficient. The existing oom killer
> implementation is hevily process centric (with memcg extension for
> grouping but not changing the overall design in principle). If you
> want to make it aware of resources which are not directly accounted to
> processes then a a new implementation is necessary IMHO. You would need
> to evaluate those resources and kill all the tasks that can hold on that
> resource.
Well the OOM killer is process centric because processes are what you
can kill.
Even the classic mm_struct based accounting includes MM_SHMEMPAGES into
the badness. So accounting shared resources as badness to make a
decision is nothing new here.
The difference is that this time the badness doesn't come from the
memory management subsystem, but rather from the I/O subsystem.
> This is also the reason why I am not really fan of the per file
> badness because it adds a notion of resource that is not process bound
> in general so it will add all sorts of weird runtime corner cases which
> are impossible to anticipate [*]. Maybe that will work in some scenarios
> but definitely not something to be done by default without users opting
> into that and being aware of consequences.
Would a kernel command line option to control the behavior be helpful here?
> There have been discussions that the existing oom implementation cannot
> fit all potential usecases so maybe we need to finally decide to use a
> plugable, BPFable etc architecture allow implementations that fit
> specific needs.
Yeah, BPF came to my mind as well. But need to talk with out experts on
that topic first.
When the OOM killer runs allocating more memory is pretty much a no-go
and I'm not sure what the requirements of running a BPF to find the
badness are.
> [*] I know it is not directly related but kinda similar. In the past
> we used to have heuristics to consider work done as a resource . That is
> kill younger processes preferably to reduce the damage. This has turned
> out to have a very unpredictable behavior and many complains by
> users. Situation has improved when the selection was solely based on
> rss. This has its own cons of course but at least they are predictable.
Good to know, thanks.
Regards,
Christian.
WARNING: multiple messages have this Message-ID (diff)
From: "Christian König" <christian.koenig@amd.com>
To: "Michal Hocko" <mhocko@suse.com>,
"Christian König" <ckoenig.leichtzumerken@gmail.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: [Nouveau] [PATCH 03/13] mm: shmem: provide oom badness for shmem files
Date: Wed, 15 Jun 2022 14:35:22 +0200 [thread overview]
Message-ID: <9e170201-35df-cfcc-8d07-2f9693278829@amd.com> (raw)
In-Reply-To: <YqdFkfLVFUD5K6EK@dhcp22.suse.cz>
Am 13.06.22 um 16:11 schrieb Michal Hocko:
> [SNIP]
>> Let me maybe get back to the initial question: We have resources which are
>> not related to the virtual address space of a process, how should we tell
>> the OOM killer about them?
> I would say memcg, but we have discussed this already...
Well memcg is at least closer to the requirements than the classic
mm_struct accounting.
It won't work for really shared buffers, but if that's the requirement
to find some doable solution for the remaining 99% then I can live with
that.
> I do not think that exposing a resource (in a form of a counter
> or something like that) is sufficient. The existing oom killer
> implementation is hevily process centric (with memcg extension for
> grouping but not changing the overall design in principle). If you
> want to make it aware of resources which are not directly accounted to
> processes then a a new implementation is necessary IMHO. You would need
> to evaluate those resources and kill all the tasks that can hold on that
> resource.
Well the OOM killer is process centric because processes are what you
can kill.
Even the classic mm_struct based accounting includes MM_SHMEMPAGES into
the badness. So accounting shared resources as badness to make a
decision is nothing new here.
The difference is that this time the badness doesn't come from the
memory management subsystem, but rather from the I/O subsystem.
> This is also the reason why I am not really fan of the per file
> badness because it adds a notion of resource that is not process bound
> in general so it will add all sorts of weird runtime corner cases which
> are impossible to anticipate [*]. Maybe that will work in some scenarios
> but definitely not something to be done by default without users opting
> into that and being aware of consequences.
Would a kernel command line option to control the behavior be helpful here?
> There have been discussions that the existing oom implementation cannot
> fit all potential usecases so maybe we need to finally decide to use a
> plugable, BPFable etc architecture allow implementations that fit
> specific needs.
Yeah, BPF came to my mind as well. But need to talk with out experts on
that topic first.
When the OOM killer runs allocating more memory is pretty much a no-go
and I'm not sure what the requirements of running a BPF to find the
badness are.
> [*] I know it is not directly related but kinda similar. In the past
> we used to have heuristics to consider work done as a resource . That is
> kill younger processes preferably to reduce the damage. This has turned
> out to have a very unpredictable behavior and many complains by
> users. Situation has improved when the selection was solely based on
> rss. This has its own cons of course but at least they are predictable.
Good to know, thanks.
Regards,
Christian.
WARNING: multiple messages have this Message-ID (diff)
From: "Christian König" <christian.koenig@amd.com>
To: "Michal Hocko" <mhocko@suse.com>,
"Christian König" <ckoenig.leichtzumerken@gmail.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, linux-tegra@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: Wed, 15 Jun 2022 14:35:22 +0200 [thread overview]
Message-ID: <9e170201-35df-cfcc-8d07-2f9693278829@amd.com> (raw)
In-Reply-To: <YqdFkfLVFUD5K6EK@dhcp22.suse.cz>
Am 13.06.22 um 16:11 schrieb Michal Hocko:
> [SNIP]
>> Let me maybe get back to the initial question: We have resources which are
>> not related to the virtual address space of a process, how should we tell
>> the OOM killer about them?
> I would say memcg, but we have discussed this already...
Well memcg is at least closer to the requirements than the classic
mm_struct accounting.
It won't work for really shared buffers, but if that's the requirement
to find some doable solution for the remaining 99% then I can live with
that.
> I do not think that exposing a resource (in a form of a counter
> or something like that) is sufficient. The existing oom killer
> implementation is hevily process centric (with memcg extension for
> grouping but not changing the overall design in principle). If you
> want to make it aware of resources which are not directly accounted to
> processes then a a new implementation is necessary IMHO. You would need
> to evaluate those resources and kill all the tasks that can hold on that
> resource.
Well the OOM killer is process centric because processes are what you
can kill.
Even the classic mm_struct based accounting includes MM_SHMEMPAGES into
the badness. So accounting shared resources as badness to make a
decision is nothing new here.
The difference is that this time the badness doesn't come from the
memory management subsystem, but rather from the I/O subsystem.
> This is also the reason why I am not really fan of the per file
> badness because it adds a notion of resource that is not process bound
> in general so it will add all sorts of weird runtime corner cases which
> are impossible to anticipate [*]. Maybe that will work in some scenarios
> but definitely not something to be done by default without users opting
> into that and being aware of consequences.
Would a kernel command line option to control the behavior be helpful here?
> There have been discussions that the existing oom implementation cannot
> fit all potential usecases so maybe we need to finally decide to use a
> plugable, BPFable etc architecture allow implementations that fit
> specific needs.
Yeah, BPF came to my mind as well. But need to talk with out experts on
that topic first.
When the OOM killer runs allocating more memory is pretty much a no-go
and I'm not sure what the requirements of running a BPF to find the
badness are.
> [*] I know it is not directly related but kinda similar. In the past
> we used to have heuristics to consider work done as a resource . That is
> kill younger processes preferably to reduce the damage. This has turned
> out to have a very unpredictable behavior and many complains by
> users. Situation has improved when the selection was solely based on
> rss. This has its own cons of course but at least they are predictable.
Good to know, thanks.
Regards,
Christian.
WARNING: multiple messages have this Message-ID (diff)
From: "Christian König" <christian.koenig@amd.com>
To: "Michal Hocko" <mhocko@suse.com>,
"Christian König" <ckoenig.leichtzumerken@gmail.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: Wed, 15 Jun 2022 14:35:22 +0200 [thread overview]
Message-ID: <9e170201-35df-cfcc-8d07-2f9693278829@amd.com> (raw)
In-Reply-To: <YqdFkfLVFUD5K6EK@dhcp22.suse.cz>
Am 13.06.22 um 16:11 schrieb Michal Hocko:
> [SNIP]
>> Let me maybe get back to the initial question: We have resources which are
>> not related to the virtual address space of a process, how should we tell
>> the OOM killer about them?
> I would say memcg, but we have discussed this already...
Well memcg is at least closer to the requirements than the classic
mm_struct accounting.
It won't work for really shared buffers, but if that's the requirement
to find some doable solution for the remaining 99% then I can live with
that.
> I do not think that exposing a resource (in a form of a counter
> or something like that) is sufficient. The existing oom killer
> implementation is hevily process centric (with memcg extension for
> grouping but not changing the overall design in principle). If you
> want to make it aware of resources which are not directly accounted to
> processes then a a new implementation is necessary IMHO. You would need
> to evaluate those resources and kill all the tasks that can hold on that
> resource.
Well the OOM killer is process centric because processes are what you
can kill.
Even the classic mm_struct based accounting includes MM_SHMEMPAGES into
the badness. So accounting shared resources as badness to make a
decision is nothing new here.
The difference is that this time the badness doesn't come from the
memory management subsystem, but rather from the I/O subsystem.
> This is also the reason why I am not really fan of the per file
> badness because it adds a notion of resource that is not process bound
> in general so it will add all sorts of weird runtime corner cases which
> are impossible to anticipate [*]. Maybe that will work in some scenarios
> but definitely not something to be done by default without users opting
> into that and being aware of consequences.
Would a kernel command line option to control the behavior be helpful here?
> There have been discussions that the existing oom implementation cannot
> fit all potential usecases so maybe we need to finally decide to use a
> plugable, BPFable etc architecture allow implementations that fit
> specific needs.
Yeah, BPF came to my mind as well. But need to talk with out experts on
that topic first.
When the OOM killer runs allocating more memory is pretty much a no-go
and I'm not sure what the requirements of running a BPF to find the
badness are.
> [*] I know it is not directly related but kinda similar. In the past
> we used to have heuristics to consider work done as a resource . That is
> kill younger processes preferably to reduce the damage. This has turned
> out to have a very unpredictable behavior and many complains by
> users. Situation has improved when the selection was solely based on
> rss. This has its own cons of course but at least they are predictable.
Good to know, thanks.
Regards,
Christian.
next prev parent reply other threads:[~2022-06-15 12:35 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 [this message]
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
2022-06-13 9:08 ` [Nouveau] " 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=9e170201-35df-cfcc-8d07-2f9693278829@amd.com \
--to=christian.koenig@amd.com \
--cc=akpm@linux-foundation.org \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=andrey.grodzovsky@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.