From: Oscar Salvador <osalvador@techadventures.net>
To: akpm@linux-foundation.org
Cc: mhocko@suse.com, dan.j.williams@intel.com, david@redhat.com,
Pavel.Tatashin@microsoft.com, Jonathan.Cameron@huawei.com,
yasu.isimatu@gmail.com, malat@debian.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, Oscar Salvador <osalvador@suse.de>
Subject: [PATCH v2 0/4] Refactor node_states_check_changes_online/offline
Date: Fri, 21 Sep 2018 15:26:30 +0200 [thread overview]
Message-ID: <20180921132634.10103-1-osalvador@techadventures.net> (raw)
From: Oscar Salvador <osalvador@suse.de>
v1 -> v2:
- Address feedback from Pavel
- Re-write patch4 his way, as it is better
- Add Reviewed-by from Pavel
---
This patchset refactors/clean ups node_states_check_changes_online/offline
functions together with node_states_set/clear_node.
The main reason behind this patchset is that currently, these
functions are suboptimal and confusing.
For example, they contain wrong statements like:
if (N_MEMORY == N_NORMAL_MEMORY)
if (N_MEMORY =! N_NORMAL_MEMORY)
if (N_MEMORY != N_HIGH_MEMORY)
if (N_MEMORY == N_HIGH_MEMORY)
These comparasions are wrong, as N_MEMORY will never be equal
to either N_NORMAL_MEMORY or N_HIGH_MEMORY.
Although the statements do not "affect" the flow because in the way
they are placed, they are completely wrong and confusing.
I caught another misuse of this in [1].
Another thing that this patchset addresses is the fact that
some functions get called twice, or even unconditionally, without
any need.
Examples of this are:
- node_states_set_node()->node_set_state(node, N_MEMORY)
* node_states_set_node() gets called whenever we online pages,
so we end up calling node_set_state(node, N_MEMORY) everytime.
To avoid this, we should check if the node is already in node_state[N_MEMORY].
- node_states_set_node()->node_set_state(node, N_HIGH_MEMORY)
* On !CONFIG_HIGH_MEMORY, N_HIGH_MEMORY == N_NORMAL_MEMORY,
but the current code sets:
status_change_nid_high = status_change_nid_normal
This means that we will call node_set_state(node, N_NORMAL_MEMORY) twice.
The fix here is to set status_change_nid_normal = -1 on such systems,
so we skip the second call.
[1] https://patchwork.kernel.org/patch/10579155/
Oscar Salvador (4):
mm/memory_hotplug: Spare unnecessary calls to node_set_state
mm/memory_hotplug: Tidy up node_states_clear_node
mm/memory_hotplug: Simplify node_states_check_changes_online
mm/memory_hotplug: Clean up node_states_check_changes_offline
mm/memory_hotplug.c | 146 ++++++++++++++--------------------------------------
1 file changed, 40 insertions(+), 106 deletions(-)
--
2.13.6
next reply other threads:[~2018-09-21 13:26 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-21 13:26 Oscar Salvador [this message]
2018-09-21 13:26 ` [PATCH v2 1/4] mm/memory_hotplug: Spare unnecessary calls to node_set_state Oscar Salvador
2018-09-21 13:26 ` [PATCH v2 2/4] mm/memory_hotplug: Tidy up node_states_clear_node Oscar Salvador
2018-09-21 13:26 ` [PATCH v2 3/4] mm/memory_hotplug: Simplify node_states_check_changes_online Oscar Salvador
2018-09-21 14:25 ` Pasha Tatashin
2018-09-21 13:26 ` [PATCH v2 4/4] mm/memory_hotplug: Clean up node_states_check_changes_offline Oscar Salvador
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=20180921132634.10103-1-osalvador@techadventures.net \
--to=osalvador@techadventures.net \
--cc=Jonathan.Cameron@huawei.com \
--cc=Pavel.Tatashin@microsoft.com \
--cc=akpm@linux-foundation.org \
--cc=dan.j.williams@intel.com \
--cc=david@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=malat@debian.org \
--cc=mhocko@suse.com \
--cc=osalvador@suse.de \
--cc=yasu.isimatu@gmail.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 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.