linux-kernel - Re: Ways to deprecate /sys/devices/system/memory/memoryX/phys

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <02cdbf90-b29f-a9ec-c83d-49f2548e3e91@redhat.com>
Date:   Fri, 11 Sep 2020 10:09:07 +0200
From:   David Hildenbrand <david@...hat.com>
To:     Michal Hocko <mhocko@...e.com>
Cc:     Dave Hansen <dave.hansen@...el.com>,
        Gerald Schaefer <gerald.schaefer@...ux.ibm.com>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        Greg KH <gregkh@...uxfoundation.org>,
        Jan Höppner <hoeppner@...ux.ibm.com>,
        Heiko Carstens <hca@...ux.ibm.com>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        linux-api@...r.kernel.org,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Ways to deprecate /sys/devices/system/memory/memoryX/phys_device
 ?

On 11.09.20 09:20, Michal Hocko wrote:
> On Thu 10-09-20 22:31:09, David Hildenbrand wrote:
>>
>>
>>> Am 10.09.2020 um 22:01 schrieb Dave Hansen <dave.hansen@...el.com>:
>>>
>>> On 9/10/20 3:20 AM, David Hildenbrand wrote:
>>>> 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.
>>
>>> 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.

Even with a new interface (that does allow for variable-sized block
sizes), we will still end up with many memory block devices. It's not
the one thing that solves all our problems.

Consider two cases:

1. Hot(un)plugging huge DIMMs: many (not all!) use cases want to
online/offline the whole thing. HW can effectively only plug/unplug the
whole thing. It makes sense in some (most?) setups to represent one DIMM
as one memory block device.

2. Hot(un)plugging small memory increments. This is mostly the case in
virtualized environments - especially hyper-v balloon, xen balloon,
virtio-mem and (drumroll) ppc dlpar and s390x standby memory. On PPC,
you want at least all (16MB!) memory block devices that can get
unplugged again individually ("LMBs") as separate memory blocks. Same on
s390x on memory increment size (currently effectively the memory block
size).

In summary, larger memory block devices mostly only make sense with
DIMMs (and for boot memory in some cases). We will still end up with
many memory block devices in other configurations.

I do agree that a "disable sysfs" option is interesting - even with
memory hotplug (we mostly need a way to configure it and a way to notify
kexec-tools about memory hot(un)plug events). I am currently (once
again) looking into improving auto-onlining support in the kernel.

Having that said, I much rather want to see smaller improvements (that
can be fine-tuned individually - like allowing variable-sized memory
blocks) than doing a switch to "new shiny" and figuring out after a
while that we need "new shiny2".

I consider removing "phys_device" as one of these tunables. The question
would be how to make such sysfs changes easy to configure
("-phys_device", "+variable_sized_blocks" ...)

-- 
Thanks,

David / dhildenb