All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: David Rientjes <rientjes@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Mel Gorman <mgorman@suse.de>,
	linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [patch -mm] mm, page_alloc: warn_alloc nodemask is NULL when cpusets are disabled
Date: Thu, 19 Jan 2017 09:57:07 +0100	[thread overview]
Message-ID: <20170119085706.GH30786@dhcp22.suse.cz> (raw)
In-Reply-To: <279f10c2-3eaa-c641-094f-3070db67d84f@suse.cz>

On Thu 19-01-17 08:29:45, Vlastimil Babka wrote:
> On 01/18/2017 10:51 PM, David Rientjes wrote:
> > The patch "mm, page_alloc: warn_alloc print nodemask" implicitly sets the 
> > allocation nodemask to cpuset_current_mems_allowed when there is no 
> > effective mempolicy.  cpuset_current_mems_allowed is only effective when 
> > cpusets are enabled, which is also printed by warn_alloc(), so setting 
> > the nodemask to cpuset_current_mems_allowed is redundant and prevents 
> > debugging issues where ac->nodemask is not set properly in the page 
> > allocator.
> > 
> > This provides better debugging output since 
> > cpuset_print_current_mems_allowed() is already provided.
> > 
> > Signed-off-by: David Rientjes <rientjes@google.com>
> 
> Yes, with my current cpuset vs mempolicy debugging experience, this is
> more useful (except how both nodemask and mems_allowed can change under
> us, so what we print here is not necessarily the same that what
> get_page_from_freelist() has seen, but that's another thing...).
> 
> But I would suggest you change the oom killer's dump_header() the same
> way than warn_alloc().

Yes please

-- 
Michal Hocko
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@kernel.org>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: David Rientjes <rientjes@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Mel Gorman <mgorman@suse.de>,
	linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [patch -mm] mm, page_alloc: warn_alloc nodemask is NULL when cpusets are disabled
Date: Thu, 19 Jan 2017 09:57:07 +0100	[thread overview]
Message-ID: <20170119085706.GH30786@dhcp22.suse.cz> (raw)
In-Reply-To: <279f10c2-3eaa-c641-094f-3070db67d84f@suse.cz>

On Thu 19-01-17 08:29:45, Vlastimil Babka wrote:
> On 01/18/2017 10:51 PM, David Rientjes wrote:
> > The patch "mm, page_alloc: warn_alloc print nodemask" implicitly sets the 
> > allocation nodemask to cpuset_current_mems_allowed when there is no 
> > effective mempolicy.  cpuset_current_mems_allowed is only effective when 
> > cpusets are enabled, which is also printed by warn_alloc(), so setting 
> > the nodemask to cpuset_current_mems_allowed is redundant and prevents 
> > debugging issues where ac->nodemask is not set properly in the page 
> > allocator.
> > 
> > This provides better debugging output since 
> > cpuset_print_current_mems_allowed() is already provided.
> > 
> > Signed-off-by: David Rientjes <rientjes@google.com>
> 
> Yes, with my current cpuset vs mempolicy debugging experience, this is
> more useful (except how both nodemask and mems_allowed can change under
> us, so what we print here is not necessarily the same that what
> get_page_from_freelist() has seen, but that's another thing...).
> 
> But I would suggest you change the oom killer's dump_header() the same
> way than warn_alloc().

Yes please

-- 
Michal Hocko
SUSE Labs

  reply	other threads:[~2017-01-19  8:57 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-18 21:51 [patch -mm] mm, page_alloc: warn_alloc nodemask is NULL when cpusets are disabled David Rientjes
2017-01-18 21:51 ` David Rientjes
2017-01-19  7:29 ` Vlastimil Babka
2017-01-19  7:29   ` Vlastimil Babka
2017-01-19  8:57   ` Michal Hocko [this message]
2017-01-19  8:57     ` Michal Hocko
2017-01-19 22:57   ` [patch] mm, oom: header " David Rientjes
2017-01-19 22:57     ` David Rientjes
2017-01-20  7:07     ` Hillf Danton
2017-01-20  7:07       ` Hillf Danton
2017-01-20 10:00       ` [patch -mm] mm, oom: header nodemask is NULL when cpusets are disabled fix David Rientjes
2017-01-20 10:00         ` David Rientjes
2017-01-20  9:00     ` [patch] mm, oom: header nodemask is NULL when cpusets are disabled Vlastimil Babka
2017-01-20  9:00       ` Vlastimil Babka
2017-01-20 10:02       ` David Rientjes
2017-01-20 10:02         ` David Rientjes
2017-01-24 10:12     ` Michal Hocko
2017-01-24 10:12       ` Michal Hocko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170119085706.GH30786@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=rientjes@google.com \
    --cc=vbabka@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.