Messages in this thread | | | Date | Wed, 07 Oct 2020 20:08:10 +0200 | From | osalvador@suse ... | Subject | Re: [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
| |