Re: Ways to deprecate /sys/devices/system/memory/memoryX/phys_device ?

From: David Hildenbrand
Date: Mon Sep 14 2020 - 08:22:40 EST

>> 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.



David / dhildenb