Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1342449 > unrolled thread

[PATCH] mm: limit direct reclaim for higher order allocations

Back to article view | Back to linux.kernel

Contents

  [PATCH] mm: limit direct reclaim for higher order allocations Rik van Riel <riel@redhat.com> - 2016-02-24 22:40 +0100
    Re: [PATCH] mm: limit direct reclaim for higher order allocations David Rientjes <rientjes@google.com> - 2016-02-24 23:20 +0100
      Re: [PATCH] mm: limit direct reclaim for higher order allocations Rik van Riel <riel@redhat.com> - 2016-02-24 23:20 +0100
        Re: [PATCH] mm: limit direct reclaim for higher order allocations Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2016-02-25 01:30 +0100
          Re: [PATCH] mm: limit direct reclaim for higher order allocations Rik van Riel <riel@redhat.com> - 2016-02-25 03:50 +0100
            Re: [PATCH] mm: limit direct reclaim for higher order allocations Joonsoo Kim <iamjoonsoo.kim@lge.com> - 2016-02-25 05:50 +0100
    Re: [PATCH] mm: limit direct reclaim for higher order allocations Andrew Morton <akpm@linux-foundation.org> - 2016-02-25 00:10 +0100
      Re: [PATCH] mm: limit direct reclaim for higher order allocations Rik van Riel <riel@redhat.com> - 2016-02-25 00:30 +0100
    Re: [PATCH] mm: limit direct reclaim for higher order allocations Michal Hocko <mhocko@kernel.org> - 2016-02-25 15:50 +0100

#1342449 — [PATCH] mm: limit direct reclaim for higher order allocations

For multi page allocations smaller than PAGE_ALLOC_COSTLY_ORDER,
the kernel will do direct reclaim if compaction failed for any
reason. This worked fine when Linux systems had 128MB RAM, but
on my 24GB system I frequently see higher order allocations
free up over 3GB of memory, pushing all kinds of things into
swap, and slowing down applications.

It would be much better to limit the amount of reclaim done,
rather than cause excessive pageout activity.

When enough memory is free to do compaction for the highest order
allocation possible, bail out of the direct page reclaim code.

On smaller systems, this may be enough to obtain contiguous
free memory areas to satisfy small allocations, continuing our
strategy of relying on luck occasionally. On larger systems,
relying on luck like that has not been working for years.

Signed-off-by: Rik van Riel <riel@redhat.com>
---
 mm/vmscan.c | 19 ++++++++-----------
 1 file changed, 8 insertions(+), 11 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index fc62546096f9..8dd15d514761 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2584,20 +2584,17 @@ static bool shrink_zones(struct zonelist *zonelist, struct scan_control *sc)
 				continue;	/* Let kswapd poll it */
 
 			/*
-			 * If we already have plenty of memory free for
-			 * compaction in this zone, don't free any more.
-			 * Even though compaction is invoked for any
-			 * non-zero order, only frequent costly order
-			 * reclamation is disruptive enough to become a
-			 * noticeable problem, like transparent huge
-			 * page allocations.
+			 * For higher order allocations, free enough memory
+			 * to be able to do compaction for the largest possible
+			 * allocation. On smaller systems, this may be enough
+			 * that smaller allocations can skip compaction, if
+			 * enough adjacent pages get freed.
 			 */
-			if (IS_ENABLED(CONFIG_COMPACTION) &&
-			    sc->order > PAGE_ALLOC_COSTLY_ORDER &&
+			if (IS_ENABLED(CONFIG_COMPACTION) && sc->order &&
 			    zonelist_zone_idx(z) <= requested_highidx &&
-			    compaction_ready(zone, sc->order)) {
+			    compaction_ready(zone, MAX_ORDER)) {
 				sc->compaction_ready = true;
-				continue;
+				return true;
 			}
 
 			/*

[toc] | [next] | [standalone]

#1342487

On Wed, 24 Feb 2016, Rik van Riel wrote:

> For multi page allocations smaller than PAGE_ALLOC_COSTLY_ORDER,
> the kernel will do direct reclaim if compaction failed for any
> reason. This worked fine when Linux systems had 128MB RAM, but
> on my 24GB system I frequently see higher order allocations
> free up over 3GB of memory, pushing all kinds of things into
> swap, and slowing down applications.
> 

Just curious, are these higher order allocations typically done by the 
slub allocator or where are they coming from?

> It would be much better to limit the amount of reclaim done,
> rather than cause excessive pageout activity.
> 
> When enough memory is free to do compaction for the highest order
> allocation possible, bail out of the direct page reclaim code.
> 
> On smaller systems, this may be enough to obtain contiguous
> free memory areas to satisfy small allocations, continuing our
> strategy of relying on luck occasionally. On larger systems,
> relying on luck like that has not been working for years.
> 
> Signed-off-by: Rik van Riel <riel@redhat.com>
> ---
>  mm/vmscan.c | 19 ++++++++-----------
>  1 file changed, 8 insertions(+), 11 deletions(-)
> 
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index fc62546096f9..8dd15d514761 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -2584,20 +2584,17 @@ static bool shrink_zones(struct zonelist *zonelist, struct scan_control *sc)
>  				continue;	/* Let kswapd poll it */
>  
>  			/*
> -			 * If we already have plenty of memory free for
> -			 * compaction in this zone, don't free any more.
> -			 * Even though compaction is invoked for any
> -			 * non-zero order, only frequent costly order
> -			 * reclamation is disruptive enough to become a
> -			 * noticeable problem, like transparent huge
> -			 * page allocations.
> +			 * For higher order allocations, free enough memory
> +			 * to be able to do compaction for the largest possible
> +			 * allocation. On smaller systems, this may be enough
> +			 * that smaller allocations can skip compaction, if
> +			 * enough adjacent pages get freed.
>  			 */
> -			if (IS_ENABLED(CONFIG_COMPACTION) &&
> -			    sc->order > PAGE_ALLOC_COSTLY_ORDER &&
> +			if (IS_ENABLED(CONFIG_COMPACTION) && sc->order &&
>  			    zonelist_zone_idx(z) <= requested_highidx &&
> -			    compaction_ready(zone, sc->order)) {
> +			    compaction_ready(zone, MAX_ORDER)) {
>  				sc->compaction_ready = true;
> -				continue;
> +				return true;
>  			}
>  
>  			/*
> 

[toc] | [prev] | [next] | [standalone]

#1342490

[Multipart message — attachments visible in raw view] — view raw

On Wed, 2016-02-24 at 14:15 -0800, David Rientjes wrote:
> On Wed, 24 Feb 2016, Rik van Riel wrote:
> 
> > For multi page allocations smaller than PAGE_ALLOC_COSTLY_ORDER,
> > the kernel will do direct reclaim if compaction failed for any
> > reason. This worked fine when Linux systems had 128MB RAM, but
> > on my 24GB system I frequently see higher order allocations
> > free up over 3GB of memory, pushing all kinds of things into
> > swap, and slowing down applications.
> > 
> 
> Just curious, are these higher order allocations typically done by
> the 
> slub allocator or where are they coming from?

These are slab allocator ones, indeed.

The allocations seem to be order 2 and 3, mostly
on behalf of the inode cache and alloc_skb.

> > It would be much better to limit the amount of reclaim done,
> > rather than cause excessive pageout activity.
> > 
> > When enough memory is free to do compaction for the highest order
> > allocation possible, bail out of the direct page reclaim code.
> > 
> > On smaller systems, this may be enough to obtain contiguous
> > free memory areas to satisfy small allocations, continuing our
> > strategy of relying on luck occasionally. On larger systems,
> > relying on luck like that has not been working for years.
> > 
> > Signed-off-by: Rik van Riel <riel@redhat.com>
> > ---
> >  mm/vmscan.c | 19 ++++++++-----------
> >  1 file changed, 8 insertions(+), 11 deletions(-)
> > 
> > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > index fc62546096f9..8dd15d514761 100644
> > --- a/mm/vmscan.c
> > +++ b/mm/vmscan.c
> > @@ -2584,20 +2584,17 @@ static bool shrink_zones(struct zonelist
> *zonelist, struct scan_control *sc)
> >                               continue;       /* Let kswapd poll it
> */
> >  
> >                       /*
> > -                      * If we already have plenty of memory free
> for
> > -                      * compaction in this zone, don't free any
> more.
> > -                      * Even though compaction is invoked for any
> > -                      * non-zero order, only frequent costly order
> > -                      * reclamation is disruptive enough to become
> a
> > -                      * noticeable problem, like transparent huge
> > -                      * page allocations.
> > +                      * For higher order allocations, free enough
> memory
> > +                      * to be able to do compaction for the
> largest possible
> > +                      * allocation. On smaller systems, this may
> be enough
> > +                      * that smaller allocations can skip
> compaction, if
> > +                      * enough adjacent pages get freed.
> >                        */
> > -                     if (IS_ENABLED(CONFIG_COMPACTION) &&
> > -                         sc->order > PAGE_ALLOC_COSTLY_ORDER &&
> > +                     if (IS_ENABLED(CONFIG_COMPACTION) && sc-
> >order &&
> >                           zonelist_zone_idx(z) <= requested_highidx
> &&
> > -                         compaction_ready(zone, sc->order)) {
> > +                         compaction_ready(zone, MAX_ORDER)) {
> >                               sc->compaction_ready = true;
> > -                             continue;
> > +                             return true;
> >                       }
> >  
> >                       /*
> > 
-- 
All Rights Reversed.

[toc] | [prev] | [next] | [standalone]

#1342544

On Wed, Feb 24, 2016 at 05:17:56PM -0500, Rik van Riel wrote:
> On Wed, 2016-02-24 at 14:15 -0800, David Rientjes wrote:
> > On Wed, 24 Feb 2016, Rik van Riel wrote:
> > 
> > > For multi page allocations smaller than PAGE_ALLOC_COSTLY_ORDER,
> > > the kernel will do direct reclaim if compaction failed for any
> > > reason. This worked fine when Linux systems had 128MB RAM, but
> > > on my 24GB system I frequently see higher order allocations
> > > free up over 3GB of memory, pushing all kinds of things into
> > > swap, and slowing down applications.
> > > 
> > 
> > Just curious, are these higher order allocations typically done by
> > the 
> > slub allocator or where are they coming from?
> 
> These are slab allocator ones, indeed.
> 
> The allocations seem to be order 2 and 3, mostly
> on behalf of the inode cache and alloc_skb.

Hello, Rik.

Could you tell me the kernel version you tested?

Commit 45eb00cd3a03 (mm/slub: don't wait for high-order page
allocation) changes slub allocator's behaviour that high order
allocation request by slub doesn't cause direct reclaim.

Thanks.

[toc] | [prev] | [next] | [standalone]

#1342686

[Multipart message — attachments visible in raw view] — view raw

On Thu, 2016-02-25 at 09:30 +0900, Joonsoo Kim wrote:
> On Wed, Feb 24, 2016 at 05:17:56PM -0500, Rik van Riel wrote:
> > On Wed, 2016-02-24 at 14:15 -0800, David Rientjes wrote:
> > > On Wed, 24 Feb 2016, Rik van Riel wrote:
> > > 
> > > > For multi page allocations smaller than
> > > > PAGE_ALLOC_COSTLY_ORDER,
> > > > the kernel will do direct reclaim if compaction failed for any
> > > > reason. This worked fine when Linux systems had 128MB RAM, but
> > > > on my 24GB system I frequently see higher order allocations
> > > > free up over 3GB of memory, pushing all kinds of things into
> > > > swap, and slowing down applications.
> > > >  
> > > 
> > > Just curious, are these higher order allocations typically done
> > > by
> > > the 
> > > slub allocator or where are they coming from?
> > 
> > These are slab allocator ones, indeed.
> > 
> > The allocations seem to be order 2 and 3, mostly
> > on behalf of the inode cache and alloc_skb.
> 
> Hello, Rik.
> 
> Could you tell me the kernel version you tested?
> 
> Commit 45eb00cd3a03 (mm/slub: don't wait for high-order page
> allocation) changes slub allocator's behaviour that high order
> allocation request by slub doesn't cause direct reclaim.

The system I observed the problem on has a
4.2 based kernel on it. That would explain.

Are we sure the problem is limited just to
slub, though?

-- 
All Rights Reversed.

[toc] | [prev] | [next] | [standalone]

#1342792

On Wed, Feb 24, 2016 at 09:47:27PM -0500, Rik van Riel wrote:
> On Thu, 2016-02-25 at 09:30 +0900, Joonsoo Kim wrote:
> > On Wed, Feb 24, 2016 at 05:17:56PM -0500, Rik van Riel wrote:
> > > On Wed, 2016-02-24 at 14:15 -0800, David Rientjes wrote:
> > > > On Wed, 24 Feb 2016, Rik van Riel wrote:
> > > > 
> > > > > For multi page allocations smaller than
> > > > > PAGE_ALLOC_COSTLY_ORDER,
> > > > > the kernel will do direct reclaim if compaction failed for any
> > > > > reason. This worked fine when Linux systems had 128MB RAM, but
> > > > > on my 24GB system I frequently see higher order allocations
> > > > > free up over 3GB of memory, pushing all kinds of things into
> > > > > swap, and slowing down applications.
> > > > >  
> > > > 
> > > > Just curious, are these higher order allocations typically done
> > > > by
> > > > the 
> > > > slub allocator or where are they coming from?
> > > 
> > > These are slab allocator ones, indeed.
> > > 
> > > The allocations seem to be order 2 and 3, mostly
> > > on behalf of the inode cache and alloc_skb.
> > 
> > Hello, Rik.
> > 
> > Could you tell me the kernel version you tested?
> > 
> > Commit 45eb00cd3a03 (mm/slub: don't wait for high-order page
> > allocation) changes slub allocator's behaviour that high order
> > allocation request by slub doesn't cause direct reclaim.
> 
> The system I observed the problem on has a
> 4.2 based kernel on it. That would explain.
> 
> Are we sure the problem is limited just to
> slub, though?

AFAIK, there is one more notable place to request high-order page,
allocation for thread_info. However, it would be much less aggressive
than slub one. Please refer THREAD_SIZE_ORDER definition.

If we need to fix this situation, I think that it is better to make
shrink_zone_memcg() to consider allocation requested order. Entering
direct reclaim means that async compaction already fails for this
low order. Although sync compaction has much more power than async one
but it is possible that compaction would not work well at that time.
Because this low order allocation is something we take care about
unlike PAGE_ALLOC_COSTLY_ORDER allocation, I think that
small amount of reclaim is better than just skipping it.

Thanks.

[toc] | [prev] | [next] | [standalone]

#1342506

On Wed, 24 Feb 2016 16:38:50 -0500 Rik van Riel <riel@redhat.com> wrote:

> For multi page allocations smaller than PAGE_ALLOC_COSTLY_ORDER,
> the kernel will do direct reclaim if compaction failed for any
> reason. This worked fine when Linux systems had 128MB RAM, but
> on my 24GB system I frequently see higher order allocations
> free up over 3GB of memory, pushing all kinds of things into
> swap, and slowing down applications.

hm.  Seems a pretty obvious flaw - why didn't we notice+fix it earlier?

> It would be much better to limit the amount of reclaim done,
> rather than cause excessive pageout activity.
> 
> When enough memory is free to do compaction for the highest order
> allocation possible, bail out of the direct page reclaim code.
> 
> On smaller systems, this may be enough to obtain contiguous
> free memory areas to satisfy small allocations, continuing our
> strategy of relying on luck occasionally. On larger systems,
> relying on luck like that has not been working for years.
> 

It would be nice to see some solid testing results on real-world
workloads?

(patch retained for linux-mm)

> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index fc62546096f9..8dd15d514761 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -2584,20 +2584,17 @@ static bool shrink_zones(struct zonelist *zonelist, struct scan_control *sc)
>  				continue;	/* Let kswapd poll it */
>  
>  			/*
> -			 * If we already have plenty of memory free for
> -			 * compaction in this zone, don't free any more.
> -			 * Even though compaction is invoked for any
> -			 * non-zero order, only frequent costly order
> -			 * reclamation is disruptive enough to become a
> -			 * noticeable problem, like transparent huge
> -			 * page allocations.
> +			 * For higher order allocations, free enough memory
> +			 * to be able to do compaction for the largest possible
> +			 * allocation. On smaller systems, this may be enough
> +			 * that smaller allocations can skip compaction, if
> +			 * enough adjacent pages get freed.
>  			 */
> -			if (IS_ENABLED(CONFIG_COMPACTION) &&
> -			    sc->order > PAGE_ALLOC_COSTLY_ORDER &&
> +			if (IS_ENABLED(CONFIG_COMPACTION) && sc->order &&
>  			    zonelist_zone_idx(z) <= requested_highidx &&
> -			    compaction_ready(zone, sc->order)) {
> +			    compaction_ready(zone, MAX_ORDER)) {
>  				sc->compaction_ready = true;
> -				continue;
> +				return true;
>  			}
>  
>  			/*

[toc] | [prev] | [next] | [standalone]

#1342516

[Multipart message — attachments visible in raw view] — view raw

On Wed, 2016-02-24 at 15:02 -0800, Andrew Morton wrote:
> On Wed, 24 Feb 2016 16:38:50 -0500 Rik van Riel <riel@redhat.com>
> wrote:
> 
> > For multi page allocations smaller than PAGE_ALLOC_COSTLY_ORDER,
> > the kernel will do direct reclaim if compaction failed for any
> > reason. This worked fine when Linux systems had 128MB RAM, but
> > on my 24GB system I frequently see higher order allocations
> > free up over 3GB of memory, pushing all kinds of things into
> > swap, and slowing down applications.
> 
> hm.  Seems a pretty obvious flaw - why didn't we notice+fix it
> earlier?

I have heard complaints about suspicious pageout
behaviour before, but had not investigated it
until recently.

> > It would be much better to limit the amount of reclaim done,
> > rather than cause excessive pageout activity.
> > 
> > When enough memory is free to do compaction for the highest order
> > allocation possible, bail out of the direct page reclaim code.
> > 
> > On smaller systems, this may be enough to obtain contiguous
> > free memory areas to satisfy small allocations, continuing our
> > strategy of relying on luck occasionally. On larger systems,
> > relying on luck like that has not been working for years.
> > 
> 
> It would be nice to see some solid testing results on real-world
> workloads?

That's why I posted it.  I suspect my workload
is not nearly as demanding as the workloads many
other people have, and this is the kind of thing
that wants some serious testing.

It might also make sense to carry it in -mm for
two full release cycles before sending it to Linus.

> (patch retained for linux-mm)
> 
> > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > index fc62546096f9..8dd15d514761 100644
> > --- a/mm/vmscan.c
> > +++ b/mm/vmscan.c
> > @@ -2584,20 +2584,17 @@ static bool shrink_zones(struct zonelist
> > *zonelist, struct scan_control *sc)
> >  				continue;	/* Let kswapd
> > poll it */
> >  
> >  			/*
> > -			 * If we already have plenty of memory
> > free for
> > -			 * compaction in this zone, don't free any
> > more.
> > -			 * Even though compaction is invoked for
> > any
> > -			 * non-zero order, only frequent costly
> > order
> > -			 * reclamation is disruptive enough to
> > become a
> > -			 * noticeable problem, like transparent
> > huge
> > -			 * page allocations.
> > +			 * For higher order allocations, free
> > enough memory
> > +			 * to be able to do compaction for the
> > largest possible
> > +			 * allocation. On smaller systems, this
> > may be enough
> > +			 * that smaller allocations can skip
> > compaction, if
> > +			 * enough adjacent pages get freed.
> >  			 */
> > -			if (IS_ENABLED(CONFIG_COMPACTION) &&
> > -			    sc->order > PAGE_ALLOC_COSTLY_ORDER &&
> > +			if (IS_ENABLED(CONFIG_COMPACTION) && sc-
> > >order &&
> >  			    zonelist_zone_idx(z) <=
> > requested_highidx &&
> > -			    compaction_ready(zone, sc->order)) {
> > +			    compaction_ready(zone, MAX_ORDER)) {
> >  				sc->compaction_ready = true;
> > -				continue;
> > +				return true;
> >  			}
> >  
> >  			/*
-- 
All Rights Reversed.

[toc] | [prev] | [next] | [standalone]

#1343221

On Wed 24-02-16 16:38:50, Rik van Riel wrote:
> For multi page allocations smaller than PAGE_ALLOC_COSTLY_ORDER,
> the kernel will do direct reclaim if compaction failed for any
> reason. This worked fine when Linux systems had 128MB RAM, but
> on my 24GB system I frequently see higher order allocations
> free up over 3GB of memory, pushing all kinds of things into
> swap, and slowing down applications.
> 
> It would be much better to limit the amount of reclaim done,
> rather than cause excessive pageout activity.
> 
> When enough memory is free to do compaction for the highest order
> allocation possible, bail out of the direct page reclaim code.
> 
> On smaller systems, this may be enough to obtain contiguous
> free memory areas to satisfy small allocations, continuing our
> strategy of relying on luck occasionally. On larger systems,
> relying on luck like that has not been working for years.

I guess I have seen the similar problem just from a different direction
though. With my oom detection rework I have started seeing pre mature
OOM killing for higher order requests (mostly order-2 from from).
This thing is that the oom rework has limitted the number of the
reclaim/compaction retries to a finit number. Currently we are relying
on zone_reclaimable which can keep the reclaim in a loop for a long time
reclaimaing order-0 pages while compaction doesn't bother to compact at
all. The reason is most probably that the compaction is mainly focused
on THP and doesn't care about !costly high order allocations. Wouldn't
it be better if the compaction tried harder for these requests rather
than falling back to the reclaim which is not guaranteed to help much?
We can compact pages if they are on the LRU even without reclaiming
them, right?

That being said, shouldn't we rather have a look at compaction than the
reclaim path?

> Signed-off-by: Rik van Riel <riel@redhat.com>
> ---
>  mm/vmscan.c | 19 ++++++++-----------
>  1 file changed, 8 insertions(+), 11 deletions(-)
> 
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index fc62546096f9..8dd15d514761 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -2584,20 +2584,17 @@ static bool shrink_zones(struct zonelist *zonelist, struct scan_control *sc)
>  				continue;	/* Let kswapd poll it */
>  
>  			/*
> -			 * If we already have plenty of memory free for
> -			 * compaction in this zone, don't free any more.
> -			 * Even though compaction is invoked for any
> -			 * non-zero order, only frequent costly order
> -			 * reclamation is disruptive enough to become a
> -			 * noticeable problem, like transparent huge
> -			 * page allocations.
> +			 * For higher order allocations, free enough memory
> +			 * to be able to do compaction for the largest possible
> +			 * allocation. On smaller systems, this may be enough
> +			 * that smaller allocations can skip compaction, if
> +			 * enough adjacent pages get freed.
>  			 */
> -			if (IS_ENABLED(CONFIG_COMPACTION) &&
> -			    sc->order > PAGE_ALLOC_COSTLY_ORDER &&
> +			if (IS_ENABLED(CONFIG_COMPACTION) && sc->order &&
>  			    zonelist_zone_idx(z) <= requested_highidx &&
> -			    compaction_ready(zone, sc->order)) {
> +			    compaction_ready(zone, MAX_ORDER)) {
>  				sc->compaction_ready = true;
> -				continue;
> +				return true;
>  			}
>  
>  			/*

-- 
Michal Hocko
SUSE Labs

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web