From: "Luck, Tony" <tony.luck@intel.com>
To: David Hildenbrand <david@redhat.com>
Cc: "Hansen, Dave" <dave.hansen@intel.com>,
"Michal Hocko" <mhocko@suse.com>,
"Gerald Schaefer" <gerald.schaefer@linux.ibm.com>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"Greg KH" <gregkh@linuxfoundation.org>,
"Jan Höppner" <hoeppner@linux.ibm.com>,
"Heiko Carstens" <hca@linux.ibm.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-api@vger.kernel.org" <linux-api@vger.kernel.org>,
"Dave Hansen" <dave.hansen@linux.intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: Ways to deprecate /sys/devices/system/memory/memoryX/phys_device ?
Date: Fri, 11 Sep 2020 20:09:47 +0000 [thread overview]
Message-ID: <64ad68af6abe4d6b9a346e777e2bd864@intel.com> (raw)
In-Reply-To: <F078F2C8-989D-4A5A-BCB8-F7E215A795A4@redhat.com>
> How would it behave after hotplugging a single DIMM - I assume a single page will only be mapped to that DIMM (otherwise a lot of stuff would habe to be moved around. Would the mapping change after a reboot - especially can a DIMM that could get hotunplugged before suddenly no longer be hotunplugged individually?
We don't currently have any platforms that would allow hot adding at the DIMM level.
The Brickland generation of E7 Xeon servers (Ivybridge, Haswell, Broadwell) allowed
for hot plugging a riser card that contained up to 12 DIMMs.
If you did add memory it would have to appear at the top of the system physical
address space. No interleave (unless you added more than one DIMM in a single
operation). After a reboot the system would likely shuffle things around to and
interleave.
-Tony
next prev parent reply other threads:[~2020-09-11 20:09 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-10 10:20 Ways to deprecate /sys/devices/system/memory/memoryX/phys_device ? David Hildenbrand
2020-09-10 20:00 ` Dave Hansen
2020-09-10 20:31 ` David Hildenbrand
2020-09-11 7:20 ` Michal Hocko
2020-09-11 8:09 ` David Hildenbrand
2020-09-11 9:12 ` Michal Hocko
2020-09-11 10:09 ` David Hildenbrand
2020-09-11 19:24 ` Dave Hansen
2020-09-11 19:35 ` Luck, Tony
2020-09-11 19:56 ` David Hildenbrand
2020-09-11 20:09 ` Luck, Tony [this message]
2020-09-11 20:49 ` David Hildenbrand
2020-09-14 11:24 ` Michal Hocko
2020-09-14 12:14 ` David Hildenbrand
2020-09-10 20:57 ` Dave Hansen
2020-09-22 13:56 ` Gerald Schaefer
2020-09-25 14:49 ` David Hildenbrand
2020-09-25 15:00 ` Greg KH
2020-09-25 15:05 ` David Hildenbrand
2020-09-25 15:39 ` Michal Hocko
2020-09-25 15:47 ` David Hildenbrand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=64ad68af6abe4d6b9a346e777e2bd864@intel.com \
--to=tony.luck@intel.com \
--cc=akpm@linux-foundation.org \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=david@redhat.com \
--cc=gerald.schaefer@linux.ibm.com \
--cc=gregkh@linuxfoundation.org \
--cc=hca@linux.ibm.com \
--cc=hoeppner@linux.ibm.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).