On Fri 13-01-17 12:31:52, Vlastimil Babka wrote:
> On 01/12/2017 02:16 PM, Michal Hocko wrote:
> > From: Michal Hocko <mhocko@xxxxxxxx>
> >
> > warn_alloc is currently used for to report an allocation failure or an
> > allocation stall. We print some details of the allocation request like
> > the gfp mask and the request order. We do not print the allocation
> > nodemask which is important when debugging the reason for the allocation
> > failure as well. We alreaddy print the nodemask in the OOM report.
> >
> > Add nodemask to warn_alloc and print it in warn_alloc as well.
>
> That's helpful, but still IMHO incomplete compared to oom killer, see below.
>
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -3031,12 +3031,13 @@ static void warn_alloc_show_mem(gfp_t gfp_mask)
> > show_mem(filter);
> > }
> >
> > -void warn_alloc(gfp_t gfp_mask, const char *fmt, ...)
> > +void warn_alloc(gfp_t gfp_mask, nodemask_t *nodemask, const char *fmt, ...)
> > {
> > struct va_format vaf;
> > va_list args;
> > static DEFINE_RATELIMIT_STATE(nopage_rs, DEFAULT_RATELIMIT_INTERVAL,
> > DEFAULT_RATELIMIT_BURST);
> > + nodemask_t *nm = (nodemask) ? nodemask : &cpuset_current_mems_allowed;
>
> Yes that's same as oom's dump_header() does it. But what if there's both
> mempolicy nodemask and cpuset at play? From oom report you'll see that as it
> also calls cpuset_print_current_mems_allowed(). So could we do that here as
> well?
OK, I will add it. It cannot be harmful.
--
Michal Hocko
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>