lkml.org 
[lkml]   [2017]   [Nov]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] mm, sparse: do not swamp log with huge vmemmap allocation failures
On Mon 06-11-17 11:14:27, Khalid Aziz wrote:
> On Mon, 2017-11-06 at 10:22 +0100, Michal Hocko wrote:
> > From: Michal Hocko <mhocko@suse.com>
> >
> > While doing a memory hotplug tests under a heavy memory pressure we
> > have
> > noticed too many page allocation failures when allocating vmemmap
> > memmap
> > backed by huge page
> > ......... deleted .........
> > +
> > + if (!warned) {
> > + warn_alloc(gfp_mask, NULL, "vmemmap alloc
> > failure: order:%u", order);
> > + warned = true;
> > + }
> >   return NULL;
> >   } else
> >   return __earlyonly_bootmem_alloc(node, size, size,
>
> This will warn once and only once after a kernel is booted. This
> condition may happen repeatedly over a long period of time with
> significant time span between two such events and it can be useful to
> know if this is happening repeatedly. There might be better ways to
> throttle the rate of warnings, something like warn once and then
> suppress warnings for the next 15 minutes (or pick any other time
> frame). If this condition happens again later, there will be another
> warning.

While this is all true I am not sure we care all that much. The failure
mode is basically not using an optimization. This is not something we
warn normally about. Even the performance degradation is a theoretical
concern which nobody has backed by real life numbers AFAIR.

If we want to make it more sophisticated I would expect some numbers to
back such a change.
--
Michal Hocko
SUSE Labs

\
 
 \ /
  Last update: 2017-11-06 19:19    [W:0.078 / U:1.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site