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]

Date:   Mon, 14 Sep 2020 14:14:03 +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
 ?

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