linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] mm/slub: check pfmemalloc_match in slab_alloc_node fastpath
@ 2022-04-09 16:02 Ohhoon Kwon
  2022-04-10  8:12 ` Hyeonggon Yoo
  0 siblings, 1 reply; 3+ messages in thread
From: Ohhoon Kwon @ 2022-04-09 16:02 UTC (permalink / raw)
  To: Christoph Lameter, Pekka Enberg, David Rientjes, Joonsoo Kim,
	Andrew Morton, Vlastimil Babka, Roman Gushchin
  Cc: Ohhoon Kwon, JaeSang Yoo, Wonhyuk Yang, Jiyoup Kim,
	Donghyeok Kim, linux-mm, linux-kernel

If current alloc context does not have __GFP_MEMALLOC in its gfpflags,
then slab objects that were previously created with __GFP_MEMALLOC
should not be given.

This criteria is well kept in slab alloc slowpath:
When gfpflags does not contain __GFP_MEMALLOC but if per-cpu slab page
was allocated with __GFP_MEMALLOC, then allocator first deactivates
per-cpu slab page and then again allocates new slab page with the
current context's gfpflags.

However, this criteria is not checked in fastpath.
It should also be checked in the fastpath, too.

Signed-off-by: Ohhoon Kwon <ohkwon1043@gmail.com>
---
 mm/slub.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/mm/slub.c b/mm/slub.c
index 74d92aa4a3a2..c77cd548e106 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -3179,7 +3179,8 @@ static __always_inline void *slab_alloc_node(struct kmem_cache *s, struct list_l
 	 * there is a suitable cpu freelist.
 	 */
 	if (IS_ENABLED(CONFIG_PREEMPT_RT) ||
-	    unlikely(!object || !slab || !node_match(slab, node))) {
+	    unlikely(!object || !slab || !node_match(slab, node) ||
+			!pfmemalloc_match(slab, gfpflags))) {
 		object = __slab_alloc(s, gfpflags, node, addr, c);
 	} else {
 		void *next_object = get_freepointer_safe(s, object);
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH] mm/slub: check pfmemalloc_match in slab_alloc_node fastpath
  2022-04-09 16:02 [PATCH] mm/slub: check pfmemalloc_match in slab_alloc_node fastpath Ohhoon Kwon
@ 2022-04-10  8:12 ` Hyeonggon Yoo
  2022-04-10 16:13   ` Ohoon Kwon
  0 siblings, 1 reply; 3+ messages in thread
From: Hyeonggon Yoo @ 2022-04-10  8:12 UTC (permalink / raw)
  To: Ohhoon Kwon
  Cc: Christoph Lameter, Pekka Enberg, David Rientjes, Joonsoo Kim,
	Andrew Morton, Vlastimil Babka, Roman Gushchin, JaeSang Yoo,
	Wonhyuk Yang, Jiyoup Kim, Donghyeok Kim, linux-mm, linux-kernel

On Sun, Apr 10, 2022 at 01:02:23AM +0900, Ohhoon Kwon wrote:
> If current alloc context does not have __GFP_MEMALLOC in its gfpflags,
> then slab objects that were previously created with __GFP_MEMALLOC
> should not be given.
> 
> This criteria is well kept in slab alloc slowpath:
> When gfpflags does not contain __GFP_MEMALLOC but if per-cpu slab page
> was allocated with __GFP_MEMALLOC, then allocator first deactivates
> per-cpu slab page and then again allocates new slab page with the
> current context's gfpflags.
> 
> However, this criteria is not checked in fastpath.
> It should also be checked in the fastpath, too.
> 
> Signed-off-by: Ohhoon Kwon <ohkwon1043@gmail.com>
> ---
>  mm/slub.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/mm/slub.c b/mm/slub.c
> index 74d92aa4a3a2..c77cd548e106 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -3179,7 +3179,8 @@ static __always_inline void *slab_alloc_node(struct kmem_cache *s, struct list_l
>  	 * there is a suitable cpu freelist.
>  	 */
>  	if (IS_ENABLED(CONFIG_PREEMPT_RT) ||
> -	    unlikely(!object || !slab || !node_match(slab, node))) {
> +	    unlikely(!object || !slab || !node_match(slab, node) ||
> +			!pfmemalloc_match(slab, gfpflags))) {
>  		object = __slab_alloc(s, gfpflags, node, addr, c);
>  	} else {
>  		void *next_object = get_freepointer_safe(s, object);

The missing pfmemalloc check in fastpath was intended.

pfmemalloc check in fast did exist in Mel's commit 072bb0aa5e0629 ("mm:
sl[au]b: add knowledge of PFMEMALLOC reserve pages").

But later removed by Christoph's commit 5091b74a95d4 ("mm: slub: optimise
the SLUB fast path to avoid pfmemalloc checks").

Any thoughts?

Thanks!

-- 
Thanks,
Hyeonggon

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] mm/slub: check pfmemalloc_match in slab_alloc_node fastpath
  2022-04-10  8:12 ` Hyeonggon Yoo
@ 2022-04-10 16:13   ` Ohoon Kwon
  0 siblings, 0 replies; 3+ messages in thread
From: Ohoon Kwon @ 2022-04-10 16:13 UTC (permalink / raw)
  To: Hyeonggon Yoo
  Cc: Christoph Lameter, Pekka Enberg, David Rientjes, Joonsoo Kim,
	Andrew Morton, Vlastimil Babka, Roman Gushchin, JaeSang Yoo,
	Wonhyuk Yang, Jiyoup Kim, Donghyeok Kim, linux-mm, linux-kernel

Oh I was not aware of those histories.
I checked the commits, and it seems it is better to leave it
optimized(as it is now).

Thanks for your help.
Ohhoon Kwon.



On Sun, Apr 10, 2022 at 5:12 PM Hyeonggon Yoo <42.hyeyoo@gmail.com> wrote:
>
> On Sun, Apr 10, 2022 at 01:02:23AM +0900, Ohhoon Kwon wrote:
> > If current alloc context does not have __GFP_MEMALLOC in its gfpflags,
> > then slab objects that were previously created with __GFP_MEMALLOC
> > should not be given.
> >
> > This criteria is well kept in slab alloc slowpath:
> > When gfpflags does not contain __GFP_MEMALLOC but if per-cpu slab page
> > was allocated with __GFP_MEMALLOC, then allocator first deactivates
> > per-cpu slab page and then again allocates new slab page with the
> > current context's gfpflags.
> >
> > However, this criteria is not checked in fastpath.
> > It should also be checked in the fastpath, too.
> >
> > Signed-off-by: Ohhoon Kwon <ohkwon1043@gmail.com>
> > ---
> >  mm/slub.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/mm/slub.c b/mm/slub.c
> > index 74d92aa4a3a2..c77cd548e106 100644
> > --- a/mm/slub.c
> > +++ b/mm/slub.c
> > @@ -3179,7 +3179,8 @@ static __always_inline void *slab_alloc_node(struct kmem_cache *s, struct list_l
> >        * there is a suitable cpu freelist.
> >        */
> >       if (IS_ENABLED(CONFIG_PREEMPT_RT) ||
> > -         unlikely(!object || !slab || !node_match(slab, node))) {
> > +         unlikely(!object || !slab || !node_match(slab, node) ||
> > +                     !pfmemalloc_match(slab, gfpflags))) {
> >               object = __slab_alloc(s, gfpflags, node, addr, c);
> >       } else {
> >               void *next_object = get_freepointer_safe(s, object);
>
> The missing pfmemalloc check in fastpath was intended.
>
> pfmemalloc check in fast did exist in Mel's commit 072bb0aa5e0629 ("mm:
> sl[au]b: add knowledge of PFMEMALLOC reserve pages").
>
> But later removed by Christoph's commit 5091b74a95d4 ("mm: slub: optimise
> the SLUB fast path to avoid pfmemalloc checks").
>
> Any thoughts?
>
> Thanks!
>
> --
> Thanks,
> Hyeonggon

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2022-04-10 16:13 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-04-09 16:02 [PATCH] mm/slub: check pfmemalloc_match in slab_alloc_node fastpath Ohhoon Kwon
2022-04-10  8:12 ` Hyeonggon Yoo
2022-04-10 16:13   ` Ohoon Kwon

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).