From: Michal Hocko <mhocko@suse.com>
To: Yafang Shao <laoar.shao@gmail.com>
Cc: Theodore Ts'o <tytso@mit.edu>, Dave Chinner <david@fromorbit.com>,
Kent Overstreet <kent.overstreet@linux.dev>,
Matthew Wilcox <willy@infradead.org>,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, Dave Chinner <dchinner@redhat.com>
Subject: Re: [PATCH] bcachefs: Switch to memalloc_flags_do() for vmalloc allocations
Date: Tue, 3 Sep 2024 16:03:56 +0200 [thread overview]
Message-ID: <ZtcXTAs2t0tM4qaA@tiehlicka> (raw)
In-Reply-To: <CALOAHbCAN8KwgxoSw4Rg2Uuwp0=LcGY8WRMqLbpEP5MkW4H_XQ@mail.gmail.com>
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
next prev parent reply other threads:[~2024-09-03 14:03 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-28 14:06 [PATCH] bcachefs: Switch to memalloc_flags_do() for vmalloc allocations Kent Overstreet
2024-08-28 18:48 ` Matthew Wilcox
2024-08-28 19:11 ` Kent Overstreet
2024-08-28 19:26 ` Michal Hocko
2024-08-28 22:58 ` Kent Overstreet
2024-08-29 7:19 ` Michal Hocko
2024-08-29 11:41 ` Kent Overstreet
2024-08-29 11:08 ` Michal Hocko
2024-08-29 11:55 ` Kent Overstreet
2024-08-29 12:34 ` Michal Hocko
2024-08-29 12:42 ` Kent Overstreet
2024-08-29 14:27 ` Dave Chinner
2024-08-30 3:39 ` Theodore Ts'o
2024-08-31 15:46 ` Kent Overstreet
2024-08-30 9:14 ` Yafang Shao
2024-08-30 15:25 ` Vlastimil Babka
2024-09-02 3:00 ` Yafang Shao
2024-09-01 3:35 ` Dave Chinner
2024-09-02 3:02 ` Yafang Shao
2024-09-02 8:11 ` Michal Hocko
2024-09-02 9:01 ` Yafang Shao
2024-09-02 9:09 ` Michal Hocko
2024-09-03 6:34 ` Yafang Shao
2024-09-03 7:18 ` Michal Hocko
2024-09-03 12:44 ` Theodore Ts'o
2024-09-03 13:15 ` Yafang Shao
2024-09-03 14:03 ` Michal Hocko [this message]
2024-09-03 13:30 ` Michal Hocko
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=ZtcXTAs2t0tM4qaA@tiehlicka \
--to=mhocko@suse.com \
--cc=david@fromorbit.com \
--cc=dchinner@redhat.com \
--cc=kent.overstreet@linux.dev \
--cc=laoar.shao@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=tytso@mit.edu \
--cc=willy@infradead.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).