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

On Thu 10-09-20 22:31:09, David Hildenbrand wrote:

quoted

Am 10.09.2020 um 22:01 schrieb Dave Hansen [off-list ref]:

On 9/10/20 3:20 AM, David Hildenbrand wrote:

quoted

I was just exploring how /sys/devices/system/memory/memoryX/phys_device
is/was used. It's one of these interfaces that most probably never
should have been added but now we are stuck with it.

While I'm all for cleanups, what specific problems is phys_device causing?

Mostly stumbling over it, understanding that it is basically unused
with new userspace for good reason, questioning its existence.

E.g., I am working on virtio-mem support for s390x. Displaying
misleading/wrong phys_device indications isn‘t particularly helpful
- especially once there are different ways to hotplug memory for an
architecture.

quoted

Are you hoping that we can just remove users of memoryX/* until there
are no more left, and this is the easiest place to start?

At least reducing it to a minimum with clear semantics. Even with
automatic onlining there are still reasons why we need to keep the
interface for now (e.g., reloading kexec to update the kdump headers
on memory hot(un)plug). But also standby memory handling on s399x
requires it (->manual onlining).

While I agree that the existing interface is far from ideal, I am not
sure it makes much sense to invest energy into cleaning it up. We can
have a pig with a lipstick but but this will not solve the underlying
problem that we have I believe. The interface doesn't scale with the
block count (especially on some platforms like ppc), it is too
inflexible (single size of the block) and many others. I believe we need
a completely new interface which would effectively deprecate the
existing one. One could still chose to use the old interface but new
usecases would use the new one ideally.

I have brought that up earlier already without much follow up
(http://lkml.kernel.org/r/20200619120704.GD12177@dhcp22.suse.cz)

-- 
Michal Hocko
SUSE Labs