On Wed 31-07-19 16:21:46, David Hildenbrand wrote: [...] > > Thinking about it some more, I believe that we can reasonably provide > > both APIs controlable by a command line parameter for backwards > > compatibility. It is the hotplug code to control sysfs APIs. E.g. > > create one sysfs entry per add_memory_resource for the new semantic. > > Yeah, but the real question is: who needs it. I can only think about > some DIMM scenarios (some, not all). I would be interested in more use > cases. Of course, to provide and maintain two APIs we need a good reason. Well, my 3TB machine that has 7 movable nodes could really go with less than $ find /sys/devices/system/memory -name "memory*" | wc -l 1729 when it doesn't really make any sense to offline less than a hotremovable entity which is the whole node effectivelly. I have seen reports where a similarly large machine chocked on boot just because of too many udev events... In other words allowing smaller granularity is a nice toy but real usecases usually work with the whole hotplugable entity (e.g. the whole ACPI container). > (one sysfs per add_memory_resource() won't cover all DIMMs completely as > far as I remember - I might be wrong, I remember there could be a > sequence of add_memory(). Also, some DIMMs might actually overlap with > memory indicated during boot - complicated stuff) Which is something we have to live with anyway due to nodes interleaving. So nothing really new. -- Michal Hocko SUSE Labs
