From: Uladzislau Rezki <urezki@gmail.com>
To: Michal Hocko <mhocko@suse.com>
Cc: Michal Hocko <mhocko@suse.com>,
Thomas Gleixner <tglx@linutronix.de>,
paulmck@kernel.org, LKML <linux-kernel@vger.kernel.org>,
RCU <rcu@vger.kernel.org>,
linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
Vlastimil Babka <vbabka@suse.cz>,
Matthew Wilcox <willy@infradead.org>,
"Theodore Y . Ts'o" <tytso@mit.edu>,
Joel Fernandes <joel@joelfernandes.org>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>
Subject: Re: [RFC-PATCH 1/2] mm: Add __GFP_NO_LOCKS flag
Date: Thu, 13 Aug 2020 15:29:31 +0200 [thread overview]
Message-ID: <20200813132931.GA26290@pc636> (raw)
In-Reply-To: <20200813095840.GA25268@pc636>
Hello, Michal.
> > On Wed 12-08-20 02:13:25, Thomas Gleixner wrote:
> > [...]
> > > I can understand your rationale and what you are trying to solve. So, if
> > > we can actually have a distinct GFP variant:
> > >
> > > GFP_I_ABSOLUTELY_HAVE_TO_DO_THAT_AND_I_KNOW_IT_CAN_FAIL_EARLY
> >
> > Even if we cannot make the zone->lock raw I would prefer to not
> > introduce a new gfp flag. Well we can do an alias for easier grepping
> > #define GFP_RT_SAFE 0
> >
> > that would imply nowait semantic and would exclude waking up kswapd as
> > well. If we can make wake up safe under RT then the alias would reflect
> > that without any code changes.
> >
> > The second, and the more important part, would be to bail out anytime
> > the page allocator is to take a lock which is not allowed in the current
> > RT context. Something like
> >
> > diff --git a/include/linux/gfp.h b/include/linux/gfp.h
> > index 67a0774e080b..3ef3ac82d110 100644
> > --- a/include/linux/gfp.h
> > +++ b/include/linux/gfp.h
> > @@ -237,6 +237,9 @@ struct vm_area_struct;
> > * that subsystems start with one of these combinations and then set/clear
> > * %__GFP_FOO flags as necessary.
> > *
> > + * %GFP_RT_SAFE users can not sleep and they are running under RT atomic context
> > + * e.g. under raw_spin_lock. Failure of an allocation is to be expected.
> > + *
> > * %GFP_ATOMIC users can not sleep and need the allocation to succeed. A lower
> > * watermark is applied to allow access to "atomic reserves"
> > *
> > @@ -293,6 +296,7 @@ struct vm_area_struct;
> > * version does not attempt reclaim/compaction at all and is by default used
> > * in page fault path, while the non-light is used by khugepaged.
> > */
> > +#define GFP_RT_SAFE 0
> > #define GFP_ATOMIC (__GFP_HIGH|__GFP_ATOMIC|__GFP_KSWAPD_RECLAIM)
> > #define GFP_KERNEL (__GFP_RECLAIM | __GFP_IO | __GFP_FS)
> > #define GFP_KERNEL_ACCOUNT (GFP_KERNEL | __GFP_ACCOUNT)
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index e028b87ce294..268ae872cc2a 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -2824,6 +2824,13 @@ static int rmqueue_bulk(struct zone *zone, unsigned int order,
> > {
> > int i, alloced = 0;
> >
> > + /*
> > + * Hard atomic contexts are not supported by the allocator for
> > + * anything but pcp requests
> > + */
> > + if (!preemtable())
> > + return 0;
> > +
> > spin_lock(&zone->lock);
> > for (i = 0; i < count; ++i) {
> > struct page *page = __rmqueue(zone, order, migratetype,
> > @@ -3371,6 +3378,13 @@ struct page *rmqueue(struct zone *preferred_zone,
> > goto out;
> > }
> >
> > + /*
> > + * Hard atomic contexts are not supported by the allocator for high
> > + * order requests
> > + */
> > + if (WARN_ON_ONCE(!preemtable()))
> > + reurn NULL;
> > +
> > /*
> > * We most definitely don't want callers attempting to
> > * allocate greater than order-1 page units with __GFP_NOFAIL.
> > @@ -4523,6 +4537,12 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,
> > (__GFP_ATOMIC|__GFP_DIRECT_RECLAIM)))
> > gfp_mask &= ~__GFP_ATOMIC;
> >
> > + /* Hard atomic contexts support is very limited to the fast path */
> > + if (!preemtable()) {
> > + WARN_ON_ONCE(gfp_mask != GFP_RT_SAFE);
> > + return NULL;
> > + }
> > +
> > retry_cpuset:
> > compaction_retries = 0;
> > no_progress_loops = 0;
> >
> > What do you think?
> >
> > > which is easy to grep for then having the page allocator go down to the
> > > point where zone lock gets involved is not the end of the world for
> > > RT in theory - unless that damned reality tells otherwise. :)
> > >
> > > The page allocator allocations should also have a limit on the number of
> > > pages and eventually also page order (need to stare at the code or let
> > > Michal educate me that the order does not matter).
> >
> > In practice anything but order 0 is out of question because we need
> > zone->lock for that currently. Maybe we can introduce pcp lists for
> > higher orders in the future - I have a vague recollection Mel was
> > playing with that some time ago.
> >
> > > To make it consistent the same GFP_ variant should allow the slab
> > > allocator go to the point where the slab cache is exhausted.
> > >
> > > Having a distinct and clearly defined GFP_ variant is really key to
> > > chase down offenders and to make reviewers double check upfront why this
> > > is absolutely required.
> >
> > Having a high level and recognizable gfp mask is OK but I would really
> > like not to introduce a dedicated flag. The page allocator should be
> > able to recognize the context which cannot be handled.
> >
> Sorry for jumping in. We can rely on preemptable() for sure, if CONFIG_PREEMPT_RT
> is enabled, something like below:
>
> if (IS_ENABLED_RT && preemptebale())
>
I was a bit out of focus and did not mention about one thing. Identifying the context
type using preemtable() primitives looks a bit not suitable, IMHO. GFP_* flags are
not supposed to identify a context type, because it is not possible for all cases.
But that i
Also, to bail out based on a context's type will not allow to get a page from atomic
contexts, what we try to achieve :)
Whereas, i mean, we do have possibility to do lock-less per-cpu-list allocation without
touching any zone lock.
if (gfp_mask == 0) {
check_pcp_lists();
if (page)
return page;
bail out here without doing farther logic, like pre-fetching.
return NULL;
}
For example consider our case:
kfree_rcu()-> raw_spin_lock() -> page_alloc-> preemtable() -> false
--
Vlad Rezki
next prev parent reply other threads:[~2020-08-13 13:29 UTC|newest]
Thread overview: 111+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-09 20:43 [RFC-PATCH 0/2] __GFP_NO_LOCKS Uladzislau Rezki (Sony)
2020-08-09 20:43 ` [RFC-PATCH 1/2] mm: Add __GFP_NO_LOCKS flag Uladzislau Rezki (Sony)
2020-08-10 12:31 ` Michal Hocko
2020-08-10 16:07 ` Uladzislau Rezki
2020-08-10 19:25 ` Michal Hocko
2020-08-11 8:19 ` Michal Hocko
2020-08-11 9:37 ` Uladzislau Rezki
2020-08-11 9:42 ` Uladzislau Rezki
2020-08-11 10:28 ` Michal Hocko
2020-08-11 10:45 ` Uladzislau Rezki
2020-08-11 10:26 ` Michal Hocko
2020-08-11 11:33 ` Uladzislau Rezki
2020-08-11 9:18 ` Uladzislau Rezki
2020-08-11 10:21 ` Michal Hocko
2020-08-11 11:10 ` Uladzislau Rezki
2020-08-11 14:44 ` Thomas Gleixner
2020-08-11 15:22 ` Thomas Gleixner
2020-08-12 11:38 ` Thomas Gleixner
2020-08-12 12:01 ` Uladzislau Rezki
2020-08-13 7:18 ` Michal Hocko
2020-08-11 15:33 ` Paul E. McKenney
2020-08-11 15:43 ` Thomas Gleixner
2020-08-11 15:56 ` Sebastian Andrzej Siewior
2020-08-11 16:02 ` Paul E. McKenney
2020-08-11 16:19 ` Paul E. McKenney
2020-08-11 19:39 ` Thomas Gleixner
2020-08-11 21:09 ` Paul E. McKenney
2020-08-12 0:13 ` Thomas Gleixner
2020-08-12 4:29 ` Paul E. McKenney
2020-08-12 8:32 ` Thomas Gleixner
2020-08-12 13:30 ` Paul E. McKenney
2020-08-13 7:50 ` Michal Hocko
2020-08-13 9:58 ` Uladzislau Rezki
2020-08-13 11:15 ` Michal Hocko
2020-08-13 13:27 ` Thomas Gleixner
2020-08-13 13:45 ` Michal Hocko
2020-08-13 14:32 ` Matthew Wilcox
2020-08-13 16:14 ` Thomas Gleixner
2020-08-13 16:22 ` Matthew Wilcox
2020-08-13 13:22 ` Thomas Gleixner
2020-08-13 13:33 ` Michal Hocko
2020-08-13 14:34 ` Thomas Gleixner
2020-08-13 14:53 ` Michal Hocko
2020-08-13 15:41 ` Paul E. McKenney
2020-08-13 15:54 ` Michal Hocko
2020-08-13 16:04 ` Paul E. McKenney
2020-08-13 16:13 ` Michal Hocko
2020-08-13 16:29 ` Paul E. McKenney
2020-08-13 17:12 ` Michal Hocko
2020-08-13 17:27 ` Paul E. McKenney
2020-08-13 18:31 ` peterz
2020-08-13 19:13 ` Michal Hocko
2020-08-13 16:20 ` Uladzislau Rezki
2020-08-13 16:36 ` Michal Hocko
2020-08-14 11:54 ` Uladzislau Rezki
2020-08-13 17:09 ` Thomas Gleixner
2020-08-13 17:22 ` Michal Hocko
2020-08-14 7:17 ` Michal Hocko
2020-08-14 12:15 ` Uladzislau Rezki
2020-08-14 12:48 ` Michal Hocko
2020-08-14 13:34 ` Paul E. McKenney
2020-08-14 14:06 ` Michal Hocko
2020-08-14 18:01 ` Paul E. McKenney
2020-08-14 23:14 ` Thomas Gleixner
2020-08-14 23:41 ` Paul E. McKenney
2020-08-15 0:43 ` Thomas Gleixner
2020-08-15 3:01 ` Paul E. McKenney
2020-08-15 8:27 ` Peter Zijlstra
2020-08-15 13:03 ` Paul E. McKenney
2020-08-15 8:42 ` Peter Zijlstra
2020-08-15 14:18 ` Paul E. McKenney
2020-08-15 14:23 ` Paul E. McKenney
2020-08-17 8:47 ` Michal Hocko
2020-08-13 18:26 ` peterz
2020-08-13 18:52 ` Paul E. McKenney
2020-08-13 22:06 ` peterz
2020-08-13 23:23 ` Paul E. McKenney
2020-08-13 23:59 ` Thomas Gleixner
2020-08-14 8:30 ` Peter Zijlstra
2020-08-14 10:23 ` peterz
2020-08-14 15:26 ` Paul E. McKenney
2020-08-14 14:14 ` Paul E. McKenney
2020-08-14 16:11 ` Paul E. McKenney
2020-08-14 17:49 ` Peter Zijlstra
2020-08-14 18:02 ` Paul E. McKenney
2020-08-14 19:33 ` Thomas Gleixner
2020-08-14 20:41 ` Paul E. McKenney
2020-08-14 21:52 ` Peter Zijlstra
2020-08-14 23:27 ` Paul E. McKenney
2020-08-14 23:40 ` Thomas Gleixner
2020-08-16 22:56 ` Uladzislau Rezki
2020-08-17 8:28 ` Michal Hocko
2020-08-17 10:36 ` Uladzislau Rezki
2020-08-17 22:28 ` Paul E. McKenney
2020-08-18 7:43 ` Michal Hocko
2020-08-18 13:53 ` Paul E. McKenney
2020-08-18 14:43 ` Thomas Gleixner
2020-08-18 16:13 ` Paul E. McKenney
2020-08-18 16:55 ` Thomas Gleixner
2020-08-18 17:13 ` Paul E. McKenney
2020-08-18 23:26 ` Thomas Gleixner
2020-08-19 23:07 ` Paul E. McKenney
2020-08-18 15:02 ` Michal Hocko
2020-08-18 15:45 ` Uladzislau Rezki
2020-08-18 16:18 ` Paul E. McKenney
2020-08-14 16:19 ` peterz
2020-08-14 18:15 ` Paul E. McKenney
2020-08-13 13:29 ` Uladzislau Rezki [this message]
2020-08-13 13:41 ` Michal Hocko
2020-08-13 14:22 ` Uladzislau Rezki
2020-08-09 20:43 ` [PATCH 2/2] rcu/tree: use " Uladzislau Rezki (Sony)
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=20200813132931.GA26290@pc636 \
--to=urezki@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=bigeasy@linutronix.de \
--cc=joel@joelfernandes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=oleksiy.avramchenko@sonymobile.com \
--cc=paulmck@kernel.org \
--cc=rcu@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=tytso@mit.edu \
--cc=vbabka@suse.cz \
--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).