From: Vlastimil Babka <vbabka@suse.cz>
To: Michal Hocko <mhocko@kernel.org>, linux-mm@kvack.org
Cc: Andrew Morton <akpm@linux-foundation.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Mel Gorman <mgorman@suse.de>,
David Rientjes <rientjes@google.com>,
Michal Hocko <mhocko@suse.com>
Subject: Re: [PATCH 4/4] lib/show_mem.c: teach show_mem to work with the given nodemask
Date: Fri, 13 Jan 2017 14:08:34 +0100 [thread overview]
Message-ID: <13903870-92bd-1ea2-aefc-0481c850da19@suse.cz> (raw)
In-Reply-To: <20170112131659.23058-5-mhocko@kernel.org>
On 01/12/2017 02:16 PM, Michal Hocko wrote:
> From: Michal Hocko <mhocko@suse.com>
>
> show_mem() allows to filter out node specific data which is irrelevant
> to the allocation request via SHOW_MEM_FILTER_NODES. The filtering
> is done in skip_free_areas_node which skips all nodes which are not
> in the mems_allowed of the current process. This works most of the
> time as expected because the nodemask shouldn't be outside of the
> allocating task but there are some exceptions. E.g. memory hotplug might
> want to request allocations from outside of the allowed nodes (see
> new_node_page).
Hm AFAICS memory hotplug's new_node_page() is restricted both by cpusets (by
using GFP_USER), and by the nodemask it constructs. That's probably a bug in
itself, as it shouldn't matter which task is triggering the offline?
Which probably means that if show_mem() wants to be really precise, it would
have to start from nodemask and intersect with cpuset when the allocation in
question cannot escape it. But if we accept that it's ok when we print too many
nodes (because we can filter them out when reading the output by having also
nodemask and mems_allowed printed), and strive only to not miss any nodes, then
this patch could really fix cases when we do miss (although new_node_page()
currently isn't such example).
Or am I wrong?
--
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>
next prev parent reply other threads:[~2017-01-13 13:08 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-12 13:16 [PATCH 0/4] show_mem updates Michal Hocko
2017-01-12 13:16 ` [PATCH 1/4] mm, page_alloc: do not report all nodes in show_mem Michal Hocko
2017-01-12 13:47 ` Mel Gorman
2017-01-14 16:26 ` Johannes Weiner
2017-01-12 13:16 ` [PATCH 2/4] mm, page_alloc: warn_alloc print nodemask Michal Hocko
2017-01-12 13:47 ` Mel Gorman
2017-01-13 11:31 ` Vlastimil Babka
2017-01-13 14:58 ` Michal Hocko
2017-01-12 13:16 ` [RFC PATCH 3/4] arch, mm: remove arch specific show_mem Michal Hocko
2017-01-12 13:48 ` Mel Gorman
2017-01-12 17:53 ` Chris Metcalf
2017-01-12 20:04 ` Helge Deller
2017-01-13 2:49 ` Xuetao Guan
2017-01-14 16:29 ` Johannes Weiner
2017-01-12 13:16 ` [PATCH 4/4] lib/show_mem.c: teach show_mem to work with the given nodemask Michal Hocko
2017-01-12 13:49 ` Mel Gorman
2017-01-13 13:08 ` Vlastimil Babka [this message]
2017-01-13 15:08 ` Michal Hocko
2017-01-13 15:30 ` Vlastimil Babka
2017-01-17 9:15 [PATCH 0/4 v2] show_mem updates Michal Hocko
2017-01-17 9:15 ` [PATCH 4/4] lib/show_mem.c: teach show_mem to work with the given nodemask 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=13903870-92bd-1ea2-aefc-0481c850da19@suse.cz \
--to=vbabka@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mhocko@kernel.org \
--cc=mhocko@suse.com \
--cc=rientjes@google.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).