[v2,0/2] handle memoryless nodes more appropriately

Message

Qi Zheng Oct. 19, 2023, 7:36 a.m. UTC

Hi all,

Currently, in the process of initialization or offline memory, memoryless
nodes will still be built into the fallback list of itself or other nodes.

This is not what we expected, so this patch series removes memoryless
nodes from the fallback list entirely.

This series is based on the next-20231018.

Comments and suggestions are welcome.

Thanks,
Qi

Changlog in v1 -> v2:
 - modify the commit message in [PATCH 1/2], mention that it can also fix the
   specific crash. (suggested by Ingo Molnar)

Qi Zheng (2):
  mm: page_alloc: skip memoryless nodes entirely
  mm: memory_hotplug: drop memoryless node from fallback lists

 mm/memory_hotplug.c | 2 +-
 mm/page_alloc.c     | 7 +++++--
 2 files changed, 6 insertions(+), 3 deletions(-)

Comments

David Hildenbrand Oct. 19, 2023, 7:56 a.m. UTC | #1

On 19.10.23 09:36, Qi Zheng wrote:
> Hi all,
> 
> Currently, in the process of initialization or offline memory, memoryless
> nodes will still be built into the fallback list of itself or other nodes.
> 
> This is not what we expected, so this patch series removes memoryless
> nodes from the fallback list entirely.

What's the end result of this change -- IOW why do we care? Patch #1 
mentions "which will reduce runtime overhead." and patch #2 mentions 
"This will incur some runtime overhead.". IIUC the comment in patch #1 
correctly, these changes don't fix anything, correct?

Did you look into showing a performance gain?

Qi Zheng Oct. 19, 2023, 8:17 a.m. UTC | #2

Hi David,

On 2023/10/19 15:56, David Hildenbrand wrote:
> On 19.10.23 09:36, Qi Zheng wrote:
>> Hi all,
>>
>> Currently, in the process of initialization or offline memory, memoryless
>> nodes will still be built into the fallback list of itself or other 
>> nodes.
>>
>> This is not what we expected, so this patch series removes memoryless
>> nodes from the fallback list entirely.
> 
> What's the end result of this change -- IOW why do we care? Patch #1 
> mentions "which will reduce runtime overhead." and patch #2 mentions 
> "This will incur some runtime overhead.". IIUC the comment in patch #1 
> correctly, these changes don't fix anything, correct?

Yes, after dropping the NODE_MIN_SIZE constrain in x86, the panic
problem fixed by this patch no longer exists (Unless there are other
architectures that have this constrain).

The reason I am re-sending this patch is that I agree with Ingo's point
of view:

```
While I agree with dropping the limitation, and I agree that
9391a3f9c7f1 should have provided more of a justification, I believe a
core MM fix is in order as well, for it to not crash.
```

I also think that core MM should be safe (not crash) even in some weird
topology.

> 
> Did you look into showing a performance gain?
> 

No, and I think the performance gain should be small, after all it just
traverses one less node. ;)

Thanks,
Qi