Messages in this thread | | | Subject | Re: [PATCH 2/2] mm, memory_hotplug: provide a more generic restrictions for memory hotplug | From | David Hildenbrand <> | Date | Fri, 5 Apr 2019 10:05:09 +0200 |
| |
On 05.04.19 09:14, Michal Hocko wrote: > On Thu 04-04-19 20:27:41, David Hildenbrand wrote: >> On 04.04.19 20:01, Oscar Salvador wrote: > [...] >>> But I am not really convinced by MHP_SYSTEM_RAM name, and I think we should stick >>> with MHP_MEMBLOCK_API because it represents __what__ is that flag about and its >>> function, e.g: create memory block devices. > > Exactly
Fine with me for keeping what Oscar has.
> >> This nicely aligns with the sub-section memory add support discussion. >> >> MHP_MEMBLOCK_API immediately implies that >> >> - memory is used as system ram. Memory can be onlined/offlined. Markers >> at sections indicate if the section is online/offline. > > No there is no implication like that. It means only that the onlined > memory has a sysfs interface. Nothing more, nothing less
As soon as there is a online/offline interface, you *can* (and user space usually *will*) online that memory. Onlining/offlining is only defined for memory to be added to the buddy - memory to be used as "system ram". Doing it for random device memory will not work / result in undefined behavior.
Not adding memory block devices for system ram will not allow user space to online/offline it and break kdump reload for hot-added memory. But memory can be onlined/offlined using internal APIs of course - if that's what you were referring to.
> > This is an internal API so we are not carving anything into the stone.
That is true.
> So can we simply start with what we have and go from there?
Sure, what Oscar does here is just a simple refactoring of the interface and I was just wondering if the interface needs a general overhaul.
>I am getting > felling that this discussion just makes the whole thing more muddy.
I think this discussion is helpful to understand how the whole thing is supposed to work :) At least on my side.
Meanwhile, I will have a look if memory block devices cannot simply be created by the caller of arch_add_memory(). At least it feels like creating memory bock devices could be factored out - I remember that it was not that easy.
--
Thanks,
David / dhildenb
| |