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

Groups > linux.kernel > #1277186 > unrolled thread

[PATCH 2/2] mm: warn about ALLOC_NO_WATERMARKS request failures

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH 2/2] mm: warn about ALLOC_NO_WATERMARKS request failures Michal Hocko <mhocko@kernel.org> - 2015-11-25 11:50 +0100
    Re: [PATCH 2/2] mm: warn about ALLOC_NO_WATERMARKS request  failures David Rientjes <rientjes@google.com> - 2015-11-25 12:00 +0100
      Re: [PATCH 2/2] mm: warn about ALLOC_NO_WATERMARKS request failures Michal Hocko <mhocko@kernel.org> - 2015-11-25 13:00 +0100
        Re: [PATCH 2/2] mm: warn about ALLOC_NO_WATERMARKS request  failures David Rientjes <rientjes@google.com> - 2015-11-25 22:10 +0100
          Re: [PATCH 2/2] mm: warn about ALLOC_NO_WATERMARKS request failures Michal Hocko <mhocko@kernel.org> - 2015-11-26 11:00 +0100
            Re: [PATCH 2/2] mm: warn about ALLOC_NO_WATERMARKS request  failures David Rientjes <rientjes@google.com> - 2015-11-30 23:30 +0100

#1277186 — [PATCH 2/2] mm: warn about ALLOC_NO_WATERMARKS request failures

From: Michal Hocko <mhocko@suse.com>

ALLOC_NO_WATERMARKS requests can dive into memory reserves without any
restriction. They are used only in the case of emergency to allow
forward memory reclaim progress assuming the caller should return the
memory in a short time (e.g. {__GFP,PF}_MEMALLOC requests or OOM victim
on the way to exit or __GFP_NOFAIL requests hitting OOM). There is no
guarantee such request succeed because memory reserves might get
depleted as well. This might be either a result of a bug where memory
reserves are abused or a result of a too optimistic configuration of
memory reserves.

This patch makes sure that the administrator gets a warning when these
requests fail with a hint that min_free_kbytes might be used to increase
the amount of memory reserves. The warning might also help us check
whether the issue is caused by a buggy user or the configuration. To
prevent from flooding the logs the warning is on off but we allow it to
trigger again after min_free_kbytes was updated. Something really bad is
clearly going on if the warning hits even after multiple updates of
min_free_kbytes.

Signed-off-by: Michal Hocko <mhocko@suse.com>
---
 mm/page_alloc.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 70db11c27046..6a05d771cb08 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -240,6 +240,8 @@ compound_page_dtor * const compound_page_dtors[] = {
 #endif
 };
 
+/* warn about depleted watermarks */
+static bool warn_alloc_no_wmarks;
 int min_free_kbytes = 1024;
 int user_min_free_kbytes = -1;
 
@@ -2642,6 +2644,13 @@ get_page_from_freelist(gfp_t gfp_mask, unsigned int order, int alloc_flags,
 	if (zonelist_rescan)
 		goto zonelist_scan;
 
+	/* WARN only once unless min_free_kbytes is updated */
+	if (warn_alloc_no_wmarks && (alloc_flags & ALLOC_NO_WATERMARKS)) {
+		warn_alloc_no_wmarks = 0;
+		WARN(1, "Memory reserves are depleted for order:%d, mode:0x%x."
+			" You might consider increasing min_free_kbytes\n",
+			order, gfp_mask);
+	}
 	return NULL;
 }
 
@@ -6048,6 +6057,9 @@ static void __setup_per_zone_wmarks(void)
 	struct zone *zone;
 	unsigned long flags;
 
+	/* Warn when ALLOC_NO_WATERMARKS request fails */
+	warn_alloc_no_wmarks = 1;
+
 	/* Calculate total number of !ZONE_HIGHMEM pages */
 	for_each_zone(zone) {
 		if (!is_highmem(zone))
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1277195 — Re: [PATCH 2/2] mm: warn about ALLOC_NO_WATERMARKS request failures

On Wed, 25 Nov 2015, Michal Hocko wrote:

> From: Michal Hocko <mhocko@suse.com>
> 
> ALLOC_NO_WATERMARKS requests can dive into memory reserves without any
> restriction. They are used only in the case of emergency to allow
> forward memory reclaim progress assuming the caller should return the
> memory in a short time (e.g. {__GFP,PF}_MEMALLOC requests or OOM victim
> on the way to exit or __GFP_NOFAIL requests hitting OOM). There is no
> guarantee such request succeed because memory reserves might get
> depleted as well. This might be either a result of a bug where memory
> reserves are abused or a result of a too optimistic configuration of
> memory reserves.
> 
> This patch makes sure that the administrator gets a warning when these
> requests fail with a hint that min_free_kbytes might be used to increase
> the amount of memory reserves. The warning might also help us check
> whether the issue is caused by a buggy user or the configuration. To
> prevent from flooding the logs the warning is on off but we allow it to
> trigger again after min_free_kbytes was updated. Something really bad is
> clearly going on if the warning hits even after multiple updates of
> min_free_kbytes.
> 
> Signed-off-by: Michal Hocko <mhocko@suse.com>
> ---
>  mm/page_alloc.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 70db11c27046..6a05d771cb08 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -240,6 +240,8 @@ compound_page_dtor * const compound_page_dtors[] = {
>  #endif
>  };
>  
> +/* warn about depleted watermarks */
> +static bool warn_alloc_no_wmarks;
>  int min_free_kbytes = 1024;
>  int user_min_free_kbytes = -1;
>  
> @@ -2642,6 +2644,13 @@ get_page_from_freelist(gfp_t gfp_mask, unsigned int order, int alloc_flags,
>  	if (zonelist_rescan)
>  		goto zonelist_scan;
>  
> +	/* WARN only once unless min_free_kbytes is updated */
> +	if (warn_alloc_no_wmarks && (alloc_flags & ALLOC_NO_WATERMARKS)) {
> +		warn_alloc_no_wmarks = 0;
> +		WARN(1, "Memory reserves are depleted for order:%d, mode:0x%x."
> +			" You might consider increasing min_free_kbytes\n",
> +			order, gfp_mask);
> +	}
>  	return NULL;
>  }
>  

Doesn't this warn for high-order allocations prior to the first call to 
direct compaction whereas min_free_kbytes may be irrelevant?  Providing 
the order is good, but there's no indication when min_free_kbytes may be 
helpful from this warning.  WARN() isn't even going to show the state of 
memory.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1277274

On Wed 25-11-15 02:59:19, David Rientjes wrote:
> On Wed, 25 Nov 2015, Michal Hocko wrote:
[...]
> > @@ -2642,6 +2644,13 @@ get_page_from_freelist(gfp_t gfp_mask, unsigned int order, int alloc_flags,
> >  	if (zonelist_rescan)
> >  		goto zonelist_scan;
> >  
> > +	/* WARN only once unless min_free_kbytes is updated */
> > +	if (warn_alloc_no_wmarks && (alloc_flags & ALLOC_NO_WATERMARKS)) {
> > +		warn_alloc_no_wmarks = 0;
> > +		WARN(1, "Memory reserves are depleted for order:%d, mode:0x%x."
> > +			" You might consider increasing min_free_kbytes\n",
> > +			order, gfp_mask);
> > +	}
> >  	return NULL;
> >  }
> >  
> 
> Doesn't this warn for high-order allocations prior to the first call to 
> direct compaction whereas min_free_kbytes may be irrelevant?

Hmm, you are concerned about high order ALLOC_NO_WATERMARKS allocation
which happen prior to compaction, right? I am wondering whether there
are reasonable chances that a compaction would make a difference if we
are so depleted that there is no single page with >= order.
ALLOC_NO_WATERMARKS with high order allocations should be rare if
existing at all.

> Providing 
> the order is good, but there's no indication when min_free_kbytes may be 
> helpful from this warning. 

I am not sure I understand what you mean here.

> WARN() isn't even going to show the state of memory.

I was considering to do that but it would make the code unnecessarily
more complex. If the allocation is allowed to fail it would dump the
allocation failure. The purpose of the message is to tell us that
reserves are not sufficient. I am not sure seeing the memory state dump
would help us much more.

-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1277797 — Re: [PATCH 2/2] mm: warn about ALLOC_NO_WATERMARKS request failures

On Wed, 25 Nov 2015, Michal Hocko wrote:

> > > @@ -2642,6 +2644,13 @@ get_page_from_freelist(gfp_t gfp_mask, unsigned int order, int alloc_flags,
> > >  	if (zonelist_rescan)
> > >  		goto zonelist_scan;
> > >  
> > > +	/* WARN only once unless min_free_kbytes is updated */
> > > +	if (warn_alloc_no_wmarks && (alloc_flags & ALLOC_NO_WATERMARKS)) {
> > > +		warn_alloc_no_wmarks = 0;
> > > +		WARN(1, "Memory reserves are depleted for order:%d, mode:0x%x."
> > > +			" You might consider increasing min_free_kbytes\n",
> > > +			order, gfp_mask);
> > > +	}
> > >  	return NULL;
> > >  }
> > >  
> > 
> > Doesn't this warn for high-order allocations prior to the first call to 
> > direct compaction whereas min_free_kbytes may be irrelevant?
> 
> Hmm, you are concerned about high order ALLOC_NO_WATERMARKS allocation
> which happen prior to compaction, right? I am wondering whether there
> are reasonable chances that a compaction would make a difference if we
> are so depleted that there is no single page with >= order.
> ALLOC_NO_WATERMARKS with high order allocations should be rare if
> existing at all.
> 

No, I'm concerned about get_page_from_freelist() failing for an order-9 
allocation due to _fragmentation_ and then emitting this warning although 
free watermarks may be gigabytes of memory higher than min watermarks.

> > Providing 
> > the order is good, but there's no indication when min_free_kbytes may be 
> > helpful from this warning. 
> 
> I am not sure I understand what you mean here.
> 

You show the order of the failed allocation in your new warning.  Good.  
It won't help to raise min_free_kbytes to infinity if the high-order 
allocation failed due to fragmentation.  Does that make sense?

> > WARN() isn't even going to show the state of memory.
> 
> I was considering to do that but it would make the code unnecessarily
> more complex. If the allocation is allowed to fail it would dump the
> allocation failure. The purpose of the message is to tell us that
> reserves are not sufficient. I am not sure seeing the memory state dump
> would help us much more.
> 

If the purpsoe of the message is to tell us when reserves are 
insufficient, it doesn't achieve that purpose if allocations fail due to 
fragmentation or lowmem_reserve_ratio.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1278125

On Wed 25-11-15 13:01:56, David Rientjes wrote:
> On Wed, 25 Nov 2015, Michal Hocko wrote:
> 
> > > > @@ -2642,6 +2644,13 @@ get_page_from_freelist(gfp_t gfp_mask, unsigned int order, int alloc_flags,
> > > >  	if (zonelist_rescan)
> > > >  		goto zonelist_scan;
> > > >  
> > > > +	/* WARN only once unless min_free_kbytes is updated */
> > > > +	if (warn_alloc_no_wmarks && (alloc_flags & ALLOC_NO_WATERMARKS)) {
> > > > +		warn_alloc_no_wmarks = 0;
> > > > +		WARN(1, "Memory reserves are depleted for order:%d, mode:0x%x."
> > > > +			" You might consider increasing min_free_kbytes\n",
> > > > +			order, gfp_mask);
> > > > +	}
> > > >  	return NULL;
> > > >  }
> > > >  
> > > 
> > > Doesn't this warn for high-order allocations prior to the first call to 
> > > direct compaction whereas min_free_kbytes may be irrelevant?
> > 
> > Hmm, you are concerned about high order ALLOC_NO_WATERMARKS allocation
> > which happen prior to compaction, right? I am wondering whether there
> > are reasonable chances that a compaction would make a difference if we
> > are so depleted that there is no single page with >= order.
> > ALLOC_NO_WATERMARKS with high order allocations should be rare if
> > existing at all.
> > 
> 
> No, I'm concerned about get_page_from_freelist() failing for an order-9 
> allocation due to _fragmentation_ and then emitting this warning although 
> free watermarks may be gigabytes of memory higher than min watermarks.

Hmm, should we allow ALLOC_NO_WATERMARKS for order-9 (or >
PAGE_ALLOC_COSTLY_ORDER for that matter) allocations though?  What would
be the point if they are allowed to fail and so they cannot be relied on
inherently?
I can see that we might do that currently - e.g. TIF_MEMDIE might be
set while doing hugetlb page allocation but I seriously doubt that this is
intentional and probably worth fixing.

> > > Providing 
> > > the order is good, but there's no indication when min_free_kbytes may be 
> > > helpful from this warning. 
> > 
> > I am not sure I understand what you mean here.
> > 
> 
> You show the order of the failed allocation in your new warning.  Good.  
> It won't help to raise min_free_kbytes to infinity if the high-order 
> allocation failed due to fragmentation.  Does that make sense?

Sure this makes sense but as I've tried to argue the warning is just a
hint. It should warn that something unexpected is happening and offer
a workaround. And yes increasing min_free_kbytes helps to keep more
high order pages availble from my experience.
If the workaround doesn't help I suspect the bug report would come more
promptly. Your example about order-9 ALLOC_NO_WATERMARKS failure is more
than exaggarated IMHO.

> > > WARN() isn't even going to show the state of memory.
> > 
> > I was considering to do that but it would make the code unnecessarily
> > more complex. If the allocation is allowed to fail it would dump the
> > allocation failure. The purpose of the message is to tell us that
> > reserves are not sufficient. I am not sure seeing the memory state dump
> > would help us much more.
> > 
> 
> If the purpsoe of the message is to tell us when reserves are 
> insufficient, it doesn't achieve that purpose if allocations fail due to 
> fragmentation or lowmem_reserve_ratio.

Do you have any better suggestion or you just think that warning about
depleted reserves doesn't make any sense at all?

-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1280368 — Re: [PATCH 2/2] mm: warn about ALLOC_NO_WATERMARKS request failures

On Thu, 26 Nov 2015, Michal Hocko wrote:

> > > > > @@ -2642,6 +2644,13 @@ get_page_from_freelist(gfp_t gfp_mask, unsigned int order, int alloc_flags,
> > > > >  	if (zonelist_rescan)
> > > > >  		goto zonelist_scan;
> > > > >  
> > > > > +	/* WARN only once unless min_free_kbytes is updated */
> > > > > +	if (warn_alloc_no_wmarks && (alloc_flags & ALLOC_NO_WATERMARKS)) {
> > > > > +		warn_alloc_no_wmarks = 0;
> > > > > +		WARN(1, "Memory reserves are depleted for order:%d, mode:0x%x."
> > > > > +			" You might consider increasing min_free_kbytes\n",
> > > > > +			order, gfp_mask);
> > > > > +	}
> > > > >  	return NULL;
> > > > >  }
> > > > >  
> > > > 
> > > > Doesn't this warn for high-order allocations prior to the first call to 
> > > > direct compaction whereas min_free_kbytes may be irrelevant?
> > > 
> > > Hmm, you are concerned about high order ALLOC_NO_WATERMARKS allocation
> > > which happen prior to compaction, right? I am wondering whether there
> > > are reasonable chances that a compaction would make a difference if we
> > > are so depleted that there is no single page with >= order.
> > > ALLOC_NO_WATERMARKS with high order allocations should be rare if
> > > existing at all.
> > > 
> > 
> > No, I'm concerned about get_page_from_freelist() failing for an order-9 
> > allocation due to _fragmentation_ and then emitting this warning although 
> > free watermarks may be gigabytes of memory higher than min watermarks.
> 
> Hmm, should we allow ALLOC_NO_WATERMARKS for order-9 (or >
> PAGE_ALLOC_COSTLY_ORDER for that matter) allocations though?  What would
> be the point if they are allowed to fail and so they cannot be relied on
> inherently?

This patch isn't addressing what orders the page allocator allows access 
to memory reserves for, I'm not sure this has anything to do with the 
warning you propose to add.

My concern is that this will start doing

	Memory reserves are depleted for order:9. You might consider increasing min_free_kbytes

in the kernel log with a long stack trace that is going to grab attention 
and then some user will actually follow the advice and see that the 
warning persists because the failure was due to fragmentation rather than 
watermarks.  It would be much better if the warning were only emitted when 
the _watermark_, not fragmentation, was the source of the failure.  That 
is very easy to do, by calling __zone_watermark_ok() for order 0.

I would also suggest that this is done in the same way that GFP_ATOMIC 
allocations fail that have depleted ALLOC_HARD and ALLOC_HARDER memory 
reserves, with something resembling a page allocation failure warning that 
actually presents useful data.  Your patch is already insufficient because 
it doesn't handle __GFP_NOWARN.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web