From: Michal Hocko <mhocko@suse.com>
To: "Paul E. McKenney" <paulmck@kernel.org>
Cc: liam.howlett@oracle.com, willy@infradead.org,
walken.cr@gmail.com, hannes@cmpxchg.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: Memory allocation on speculative fastpaths
Date: Tue, 3 May 2022 18:04:13 +0200 [thread overview]
Message-ID: <YnFSfc8BR8CadOtw@dhcp22.suse.cz> (raw)
In-Reply-To: <20220503155913.GA1187610@paulmck-ThinkPad-P17-Gen-1>
On Tue 03-05-22 08:59:13, Paul E. McKenney wrote:
> Hello!
>
> Just following up from off-list discussions yesterday.
>
> The requirements to allocate on an RCU-protected speculative fastpath
> seem to be as follows:
>
> 1. Never sleep.
> 2. Never reclaim.
> 3. Leave emergency pools alone.
>
> Any others?
>
> If those rules suffice, and if my understanding of the GFP flags is
> correct (ha!!!), then the following GFP flags should cover this:
>
> __GFP_NOMEMALLOC | __GFP_NOWARN
GFP_NOWAIT | __GFP_NOMEMALLOC | __GFP_NOWARN
> Or is this just a fancy way of always returning NULL or some such? ;-)
It could fail quite easily. We would also want to guarantee (by
documenting I guess) that the page allocator never does anything that
would depend or invoke rcu_synchronize or something like that.
I believe this is the case currently.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2022-05-03 16:04 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-03 15:59 Memory allocation on speculative fastpaths Paul E. McKenney
2022-05-03 16:04 ` Michal Hocko [this message]
2022-05-03 16:39 ` Paul E. McKenney
2022-05-03 18:28 ` Matthew Wilcox
2022-05-03 23:15 ` Suren Baghdasaryan
2022-05-03 23:45 ` Michal Hocko
2022-05-04 0:22 ` Matthew Wilcox
2022-05-04 16:23 ` Johannes Weiner
2022-05-24 20:37 ` Vlastimil Babka
2022-05-25 13:12 ` Johannes Weiner
2022-05-04 8:20 ` Michel Lespinasse
2022-05-04 16:52 ` Matthew Wilcox
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=YnFSfc8BR8CadOtw@dhcp22.suse.cz \
--to=mhocko@suse.com \
--cc=hannes@cmpxchg.org \
--cc=liam.howlett@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=paulmck@kernel.org \
--cc=walken.cr@gmail.com \
--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 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.