lkml.org 
[lkml]   [2015]   [Nov]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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.


\
 
 \ /
  Last update: 2015-11-25 22:21    [W:0.971 / U:1.132 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site