>> Otherwise, hot(un)plugging smaller granularity behaves more like memory >> ballooning (and I think I don't have to tell you that ballooning is used >> excessively even though it wastes memory on metadata ;) ). Anyhow, >> that's another discussion. > > Yeah, I am aware of that. And honestly subsection offlining makes very > little sense to me. It was hard to argue against that for nvdimm > usecases where we simply had to workaround the reality where devices > couldn't have been aligned properly. I do not think we want to claim a > support for general hotplug though. Totally agree, I also don't want to see actual sub-section onlining/offlining in the core (e.g., virtio-mem emulates that on top, but it behaves a lot more like memory ballooning). > > [...] > >>> There is only one certainty. Providing a long term interface with ever >>> growing (ab)users is a hard target. And shinyN might be needed in the >>> end. Who knows. My main point is that the existing interface is hitting >>> a wall on usecases which _do_not_care_ about memory hotplug. And that is >>> something we should be looking at. >> >> Agreed. I can see 3 scenarios >> >> a) no memory hotplug support, no sysfs. >> b) memory hotplug support, no sysfs >> c) memory hotplug support, sysfs >> >> Starting with a) and c) is the easiest way to go. > > Yes, the first and the simplest way would be to provide > memory_hotplug=[disabled|v1] > > where disabled would be no sysfs interface, v1 would be the existing > infrastructure. I would hope to land with v2 in a future which would > provide a new interface. > Agreed. -- Thanks, David / dhildenb
