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
