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

On Fri 25-09-20 16:49:28, David Hildenbrand wrote:

quoted

quoted

There were once RFC patches to make use of it in ACPI, but it could be
solved using different interfaces [1].


While I'd love to rip it out completely, I think it would break old
lsmem/chmem completely - and I assume that's not acceptable. I was
wondering what would be considered safe to do now/in the future:

1. Make it always return 0 (just as if "sclp.rzm" would be set to 0 on
s390x). This will make old lsmem/chmem behave differently after
switching to a new kernel, like if sclp.rzm would not be set by HW -
AFAIU, it will assume all memory is in a single memory increment. Do we
care?

No, at least not until that kernel change would be backported to some
old distribution level where we still use lsmem/chmem from s390-tools.
Given that this is just some clean-up w/o any functional benefit, and
hopefully w/o any negative impact, I think we can safely assume that no
distributor will do that "just for fun".

Even if there would be good reasons for backports, then I guess we also
have good reasons for backporting / switching to the util-linux version
of lsmem / chmem for such distribution levels. Alternatively, adjust the
s390-tools lsmem / chmem there.

But I would rather "rip it out completely" than just return 0. You'd
need some lsmem / chmem changes anyway, at least in case this would
ever be backported.

Thanks for your input Gerald.

So unless people would be running shiny new kernels on older
distributions it shouldn't be a problem (and I don't think we care too
much about something like that). I don't expect something like that to
get backported - there is absolutely no reason to do so IMHO.

Ohh, there are many people running current Linus tree on an older
distribution. Including me.

quoted

quoted

2. Restrict it to s390x only. It always returned 0 on other
architectures, I was not able to find any user.

I think 2 should be safe to do (never used on other archs). I do wonder
what the feelings are about 1.

Please don't add any s390-specific workarounds here, that does not
really sound like a clean-up, rather the opposite.

People seem to have different opinions here. I'm happy as long as we can
get rid of it (either now, or in the future with a new model).

quoted

That being said, I do not really see the benefit of this change at
all. As Michal mentioned, there really should be some more fundamental
change. And from the rest of this thread, it also seems that phys_device
usage might not be the biggest issue here.

As I already expressed, I am more of a friend of small, incremental
changes than having a single big world switch where everything will be
shiny and perfect.

(Deprecating it now - in any way - stops any new users from appearing -
both, in the kernel and from user space - eventually making the big
world switch later a little easier because there is one thing less that
vanished)

Realistically people do not care about deprecation all that much. They
simply use whatever they can find or somebody will show them. Really,
deprecation has never really worked. The only thing that worked was to
remove the functionality and then wait for somebody to complain and
revert or somehow allow the functionality without necessity to alter the
userspace.

As much as I would like to remove as much crud as possible I strongly
suspect that the existing hotplug interface is just a lost case and it
doesn't make for the best used time to put a lip stick on a pig. Even if
we remove this particular interface we are not going to get rid of a lot
of code or we won't gain any more sensible semantic, right?
-- 
Michal Hocko
SUSE Labs