On Fri 05-04-19 10:05:09, David Hildenbrand wrote: > 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. No, not really. We really do not care where the memory comes from. Is it RAM, NVDIMM, $FOO_BAR_OF_A_FUTURE_BUZZ. We only do care that the memory can be onlined - user triggered associated with a zone. The memory even doesn't have to go to the page allocator. -- Michal Hocko SUSE Labs
