linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.com>
To: Yafang Shao <laoar.shao@gmail.com>
Cc: 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: Mon, 2 Sep 2024 11:09:02 +0200	[thread overview]
Message-ID: <ZtWArlHgX8JnZjFm@tiehlicka> (raw)
In-Reply-To: <CALOAHbAbzJL31jeGfXnbXmbXMpPv-Ak3o3t0tusjs-N-NHisiQ@mail.gmail.com>

On Mon 02-09-24 17:01:12, Yafang Shao wrote:
> > I really do not see why GFP_NOFAIL should be any special in this
> > specific case.
> 
> I believe there's no way to stop it from looping, even if you
> implement a sophisticated user space OOM killer. ;)

User space OOM killer should be helping to replenish a free memory and
we have some heuristics to help NOFAIL users out with some portion of
memory reserves already IIRC. So we do already give them some special
treatment in the page allocator path. Not so much in the reclaim path.
-- 
Michal Hocko
SUSE Labs


  reply	other threads:[~2024-09-02  9:09 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-28 14:06 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 [this message]
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
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=ZtWArlHgX8JnZjFm@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=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