[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3b079fda-4e89-b61b-0aca-a0c4ae834fd8@intel.com>
Date: Fri, 11 Sep 2020 12:24:12 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: David Hildenbrand <david@...hat.com>,
Michal Hocko <mhocko@...e.com>
Cc: 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>,
"Luck, Tony" <tony.luck@...el.com>
Subject: Re: Ways to deprecate /sys/devices/system/memory/memoryX/phys_device
?
On 9/11/20 3:09 AM, David Hildenbrand wrote:
> Maybe we can derive the actual DIMMs from some ACPI tables (SRAT?),
> instead of relying on e820/"System RAM resources" - I have no clue.
It's actually really hard to map a DIMM to a physical address.
Interleaving can mean that one page actually spans a bunch of DIMMs.
For NVDIMMs, the interleaving is configurable and different namespaces
on the system can have different interleaving properties.
The EDAC drivers do the physical address to DIMM lookups, but they're
quite messy. There isn't a simple table for it IIRC. *But* this turns
out not to be a problem for memory hotplug because if you're
interleaving, you can't just remove one DIMM in an interleave set anyway.
Right now, I think we just depend on ACPI to _request_ hot remove in a
size which will allow the hardware to be removed.
Anyway, I just wanted to point out the M:N relationship between pages
and DIMMs.
Maybe we should start with an erring of grievances against the old
interfaces and then start coming up with the requirements for a new one.
I'll start a list in a Google Doc unless someone has a better idea.
Powered by blists - more mailing lists