Nouveau - Jun 2022 - [PATCH 03/13] mm: shmem: provide oom badness for shmem files

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.

On Wed 15-06-22 14:35:22, Christian K?nig wrote:
[...]
> 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.
Yeah, it is nothing really new but it also doesn't mean it is an example
worth following as this doesn't really work currently. Also please note
that MM_SHMEMPAGES is counting at least something process specific as
those pages are mapped in to the process (and with enough of wishful
thinking unmapping can drop the last reference and free something up
actually) . With generic per-file memory this is even more detached from
process.
> 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?
I am not sure what would be the proper way to control that that would be
future extensible. Kernel command line is certainly and option but if we
want to extend that to module like or eBPF interface then it wouldn't
stand a future test very quickly.

-- 
Michal Hocko
SUSE Labs

Am 15.06.22 um 15:15 schrieb Michal Hocko:
> On Wed 15-06-22 14:35:22, Christian K?nig wrote:
> [...]
>> 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.
> Yeah, it is nothing really new but it also doesn't mean it is an
example
> worth following as this doesn't really work currently. Also please note
> that MM_SHMEMPAGES is counting at least something process specific as
> those pages are mapped in to the process (and with enough of wishful
> thinking unmapping can drop the last reference and free something up
> actually) . With generic per-file memory this is even more detached from
> process.
But this is exactly the use case here. See I do have the 1% which is 
shared between processes, but 99% of the allocations only one process 
has a reference to them.

So that wishful thinking that we can drop the last reference when we 
kill this specific process is perfectly justified.

It can be that this doesn't fit all use cases for the shmem file, but it 
certainly does for DRM and DMA-buf.
>> 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?
> I am not sure what would be the proper way to control that that would be
> future extensible. Kernel command line is certainly and option but if we
> want to extend that to module like or eBPF interface then it wouldn't
> stand a future test very quickly.
Well kernel command lines are not really meant to be stable, aren't they?

Regards,
Christian.