On 31.07.19 16:37, Michal Hocko wrote: > 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> The question is if it would be sufficient to increase the memory block size even further for these kinds of systems (e.g., via a boot parameter - I think we have that on uv systems) instead of having blocks of different sizes. Say, 128GB blocks because you're not going to hotplug 128MB DIMMs into such a system - at least that's my guess ;) > 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). -- Thanks, David / dhildenb
