lkml.org 
[lkml]   [2020]   [Oct]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC][PATCH 3/9] mm/migrate: update migration order during on hotplug events
On 2020-10-07 18:17, Dave Hansen wrote:
> From: Dave Hansen <dave.hansen@linux.intel.com>
>
> Reclaim-based migration is attempting to optimize data placement in
> memory based on the system topology. If the system changes, so must
> the migration ordering.
>
> The implementation here is pretty simple and entirely unoptimized. On
> any memory or CPU hotplug events, assume that a node was added or
> removed and recalculate all migration targets. This ensures that the
> node_demotion[] array is always ready to be used in case the new
> reclaim mode is enabled.
>
> This recalculation is far from optimal, most glaringly that it does
> not even attempt to figure out if nodes are actually coming or going.
> But, given the expected paucity of hotplug events, this should be
> fine.

Hi Dave,

I am still going through all the details, but just wanted to comment
early on this one.
Could not you hook into __try_online_node/try_offline_node?

In there we check whether a node should be brought up or removed due to
lack of cpus and memory.
That is being checked during hot-remove operations.

We also have node_states_check_changes_{offline,online} and their pair
node_states_{set,clear}_node, that checks during online/offline stages
which states should be removed from the node, but that is only wrt.
memory (I guess we would only be interested in N_MEMORY).

Thanks

\
 
 \ /
  Last update: 2020-10-07 20:09    [W:0.153 / U:1.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site