From: Michal Hocko <mhocko@suse.com>
To: Tejun Heo <tj@kernel.org>
Cc: Dennis Zhou <dennis@kernel.org>,
Filipe Manana <fdmanana@suse.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mm, percpu: do not consider sleepable allocations atomic
Date: Fri, 14 Feb 2025 16:43:15 +0100 [thread overview]
Message-ID: <Z69kkwVJuRIWjJ8K@tiehlicka> (raw)
In-Reply-To: <Z60S4NMUzzKbW5HY@slm.duckdns.org>
On Wed 12-02-25 11:30:08, Tejun Heo wrote:
> Hello,
>
> On Wed, Feb 12, 2025 at 09:53:20PM +0100, Michal Hocko wrote:
> ...
> > > Hmm... you'd a better judge on whether that'd be okay or not but it does
> > > bother me that we might be increasing the chance of allocation failures for
> > > GFP_KERNEL users at least under memory pressure.
> >
> > Nope, this will not change the allocation failure mode. Reclaim
> > constrains do not change the failure mode they just change how much the
> > allocation might struggle to reclaim to succeed.
> >
> > My undocumented assumption (another dept on my end) is that pcp
> > allocations are no hot paths. So the worst case is that GFP_KERNEL
> > pcp_allocation could have been satisfied _easier_ (i.e. faster) because
> > it could have reclaimed fs/io caches and now it needs to rely on kswapd
> > to do that on memory tight situations. On the other hand we have a
> > situation when NOIO/FS allocations fail prematurely so there is
> > certainly some pros and cons.
>
> I'm having a hard time following. Are you saying that it won't increase the
> likelihood of allocation failures even under memory pressure but that it
> might just make allocations take longer to succeed?
yes, this is like any other NOFS/NOIO allocation non-costly
(<=PAGE_ALLOC_COSTLY_ORDER) which effectively never fail.
--
Michal Hocko
SUSE Labs
prev parent reply other threads:[~2025-02-14 15:43 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-06 12:26 [PATCH] mm, percpu: do not consider sleepable allocations atomic Michal Hocko
2025-02-11 15:05 ` Vlastimil Babka
2025-02-11 20:55 ` Tejun Heo
2025-02-12 16:57 ` Michal Hocko
2025-02-12 18:14 ` Tejun Heo
2025-02-12 20:53 ` Michal Hocko
2025-02-12 21:30 ` Tejun Heo
2025-02-12 21:39 ` Dennis Zhou
2025-02-14 15:52 ` Michal Hocko
2025-02-21 2:36 ` Dennis Zhou
2025-02-21 9:48 ` Vlastimil Babka
2025-03-05 15:10 ` Michal Hocko
2025-03-05 15:35 ` Vlastimil Babka
2025-02-14 15:43 ` Michal Hocko [this message]
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=Z69kkwVJuRIWjJ8K@tiehlicka \
--to=mhocko@suse.com \
--cc=akpm@linux-foundation.org \
--cc=dennis@kernel.org \
--cc=fdmanana@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=tj@kernel.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 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.