Re: [PATCH 03/10] mm/migrate: update node demotion order during on hotplug events

2021-04-12 Thread David Hildenbrand
On 12.04.21 09:19, Oscar Salvador wrote: On Fri, Apr 09, 2021 at 08:59:21PM +0200, David Hildenbrand wrote: The only way to add more System RAM is via add_memory() and friends like add_memory_driver_managed(). These all require CONFIG_MEMORY_HOTPLUG. Yeah, my point was more towards whether

Re: [PATCH 03/10] mm/migrate: update node demotion order during on hotplug events

2021-04-12 Thread Oscar Salvador
On Fri, Apr 09, 2021 at 08:59:21PM +0200, David Hildenbrand wrote: > The only way to add more System RAM is via add_memory() and friends like > add_memory_driver_managed(). These all require CONFIG_MEMORY_HOTPLUG. Yeah, my point was more towards whether PMEM can come in a way that it does not

Re: [PATCH 03/10] mm/migrate: update node demotion order during on hotplug events

2021-04-09 Thread David Hildenbrand
On 09.04.21 12:14, Oscar Salvador wrote: On Thu, Apr 08, 2021 at 11:52:51AM +0200, Oscar Salvador wrote: I am not really into PMEM, and I ignore whether we need CONFIG_MEMORY_HOTPLUG in order to have such memory on the system. If so, the following can be partly ignored. Ok, I refreshed by

Re: [PATCH 03/10] mm/migrate: update node demotion order during on hotplug events

2021-04-09 Thread Oscar Salvador
On Fri, Apr 09, 2021 at 12:14:04PM +0200, Oscar Salvador wrote: > On Thu, Apr 08, 2021 at 11:52:51AM +0200, Oscar Salvador wrote: > > I am not really into PMEM, and I ignore whether we need > > CONFIG_MEMORY_HOTPLUG in order to have such memory on the system. > > If so, the following can be partly

Re: [PATCH 03/10] mm/migrate: update node demotion order during on hotplug events

2021-04-09 Thread Oscar Salvador
On Thu, Apr 08, 2021 at 11:52:51AM +0200, Oscar Salvador wrote: > I am not really into PMEM, and I ignore whether we need > CONFIG_MEMORY_HOTPLUG in order to have such memory on the system. > If so, the following can be partly ignored. Ok, I refreshed by memory with [1]. >From that, it seems that

Re: [PATCH 03/10] mm/migrate: update node demotion order during on hotplug events

2021-04-08 Thread Oscar Salvador
On Thu, Apr 01, 2021 at 11:32:21AM -0700, Dave Hansen wrote: > > From: Dave Hansen > > 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 is conceptually

[PATCH 03/10] mm/migrate: update node demotion order during on hotplug events

2021-04-01 Thread Dave Hansen
From: Dave Hansen 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 is conceptually simple and entirely unoptimized. On any memory or CPU hotplug events, assume

Re: [PATCH 03/10] mm/migrate: update node demotion order during on hotplug events

2021-03-09 Thread Dave Hansen
On 3/8/21 4:03 PM, Yang Shi wrote: >> +static int __meminit migrate_on_reclaim_callback(struct notifier_block >> *self, >> +unsigned long action, void >> *arg) >> +{ >> + switch (action) { >> + case MEM_GOING_OFFLINE: >> +

Re: [PATCH 03/10] mm/migrate: update node demotion order during on hotplug events

2021-03-08 Thread Yang Shi
On Thu, Mar 4, 2021 at 4:00 PM Dave Hansen wrote: > > > From: Dave Hansen > > 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 is conceptually simple and

[PATCH 03/10] mm/migrate: update node demotion order during on hotplug events

2021-03-04 Thread Dave Hansen
From: Dave Hansen 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 is conceptually simple and entirely unoptimized. On any memory or CPU hotplug events, assume