linux-kernel - Re: [PATCH] bcachefs: Switch to memalloc_flags

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] [day] [month] [year] [list]

Message-ID: <ZtcXTAs2t0tM4qaA@tiehlicka>
Date: Tue, 3 Sep 2024 16:03:56 +0200
From: Michal Hocko <mhocko@...e.com>
To: Yafang Shao <laoar.shao@...il.com>
Cc: Theodore Ts'o <tytso@....edu>, Dave Chinner <david@...morbit.com>,
	Kent Overstreet <kent.overstreet@...ux.dev>,
	Matthew Wilcox <willy@...radead.org>, linux-fsdevel@...r.kernel.org,
	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	Dave Chinner <dchinner@...hat.com>
Subject: Re: [PATCH] bcachefs: Switch to memalloc_flags_do() for vmalloc
 allocations

On Tue 03-09-24 21:15:59, Yafang Shao wrote:
[...]
> I completely agree with your point. However, in the real world, things
> don't always work as expected, which is why it's crucial to ensure the
> OOM killer is effective during system thrashing. Unfortunately, the
> kernel's OOM killer doesn't always perform as expected, particularly
> under heavy thrashing. This is one reason why user-space OOM killers
> like oomd exist.

I do undestand your point. On the other hand over a long time seeing all
different usecases we have concluded that the OOM killer should be
really conservative last resort. More agressive OOM policies should be
implemented by userspace to prevent from regressions in other usecases.

That doesn't really mean improvements to the kernel oom killer are not
welcome or impossible. The bar is just quite hard as the wide variety of
workloads is really hard to support. Heavy trashing is one example.
Different workloads will have a different understanding what that means
actually.
-- 
Michal Hocko
SUSE Labs