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?
Thanks.
--
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>