From: Dan Williams <dan.j.williams@intel.com>
To: "Yasunori Gotou (Fujitsu)" <y-goto@fujitsu.com>,
'Dan Williams' <dan.j.williams@intel.com>,
"linux-cxl@vger.kernel.org" <linux-cxl@vger.kernel.org>
Subject: RE: Questions about CXL device (type 3 memory) hotplug
Date: Wed, 24 May 2023 13:51:18 -0700 [thread overview]
Message-ID: <646e78c67ce17_33fb329432@dwillia2-xfh.jf.intel.com.notmuch> (raw)
In-Reply-To: <TYWPR01MB10082A58633DCCB1AAC5DDC3C90419@TYWPR01MB10082.jpnprd01.prod.outlook.com>
Yasunori Gotou (Fujitsu) wrote:
> > Yasunori Gotou (Fujitsu) wrote:
[..]
> > > If a block hotremove sequence fails in the device, its user would like
> > > to keep the device online to postpone replacing it or select other device for
> > device pooling. (vice vesa).
> > > I don't find which component handle this situation.
> >
> > It depends on how the memory is onlined and whether it gets pinned by the
> > kernel. As long as all of the memory is onlined to ZONE_MOVABLE then there is
> > a good chance to be able to get it back. However, ZONE_MOVABLE is not a
> > guarantee that memory can be removed later, and ZONE_MOVABLE requires
> > some ratio of ZONE_NORMAL memory to be present to make it usable. See
> > "Zone Imbalances" in Documentation/admin-guide/mm/memory-hotplug.rst.
>
> I know it. Probably, I'm the first person who proposed that kernel divides its memory into
> movable and not movable area. (IIRC, it was BOF at Ottawa Linux Symposium 2004 or 2005).
> Actually, my name is still remain in git blame in the empty lines of the document.
> ----
> ac3332c44767b Documentation/admin-guide/mm/memory-hotplug.rst (David Hildenbrand 2021-09-07 19:54:49 -0700 4) Memory Hot(Un)Plug
> ac3332c44767b Documentation/admin-guide/mm/memory-hotplug.rst (David Hildenbrand 2021-09-07 19:54:49 -0700 5) ==================
> 6867c9310d5da Documentation/memory-hotplug.txt (Yasunori Goto 2007-08-10 13:00:59 -0700 6)
> :
> ---
> I'm glad to see many people have enhanced it after leaving from working for memory-hotplug 😊.
Nice! Yeah, I have noticed that most times when I think I need something
new for memory hotplug and CXL I run into David Hildenbrand's work
associated with virtio-mem.
> In my understanding, one of the big reason of memory hotplug failure is long term pin user pages
> like Infiniband RDMA, and I guess that or any similar features may have same problem.
> Many CXL devices like smartNIC will have such feature.
> Because It has ambivalent requirements.
> - To achieve fast data transfer, such feature want to skip the kernel layer and pin user pages
> to transfer data directly. The most of CXL Device like Smart NIC will want to use it.
> - On the other hand, kernel has responsibility of such area management. Memory hotplug is one example of it,
> and it will be important for CXL memory pool.
>
> I think it is same with the issue FS-DAX vs. RDMA, and On Demand Paging is only one solution for it.
> I expect ODP may helpful for memory hotplug too.
It's going to be interesting. Yes, as memory becomes more dynamic, long
term page pinning is going to become more and more painful. It's even
worse because it's not just RDMA that causes the problem it's also any
device assigment to a guest VM that wants to pin all host pages backing
guest memory.
> About ratio problem between ZONE_NORMAL and ZONE_MOVABLE,
> I think user/platform will configure that DDR DRAM will be ZONE_NORMAL, and CXL memory pool will
> be ZONE_MOVABLE. It is easy for them to understand.
While that it is easy to understand, I worry that is in conflict with
one of the main value propositions of CXL which is vastly expanded
memory capacity. The conflict comes if the capacity of inexpensive CXL
outpaces the ZONE_NORMAL requirements that can be satisified from
locally attached DDR.
next prev parent reply other threads:[~2023-05-24 20:51 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-22 8:06 Questions about CXL device (type 3 memory) hotplug Yasunori Gotou (Fujitsu)
2023-05-23 0:11 ` Dan Williams
2023-05-23 8:31 ` Yasunori Gotou (Fujitsu)
2023-05-23 17:36 ` Dan Williams
2023-05-24 11:12 ` Yasunori Gotou (Fujitsu)
2023-05-24 20:51 ` Dan Williams [this message]
2023-05-25 10:32 ` Yasunori Gotou (Fujitsu)
2023-05-26 8:05 ` Yasunori Gotou (Fujitsu)
2023-05-26 14:48 ` Dan Williams
2023-05-29 8:07 ` Yasunori Gotou (Fujitsu)
2023-06-06 17:58 ` Dan Williams
2023-06-08 7:39 ` Yasunori Gotou (Fujitsu)
2023-06-08 18:37 ` Dan Williams
2023-06-09 1:02 ` Yasunori Gotou (Fujitsu)
2023-05-23 13:34 ` Vikram Sethi
2023-05-23 18:40 ` Dan Williams
2023-05-24 0:02 ` Vikram Sethi
2023-05-24 4:03 ` Dan Williams
2023-05-24 14:47 ` Vikram Sethi
2023-05-24 21:20 ` Dan Williams
2023-05-31 4:25 ` Vikram Sethi
2023-06-06 20:54 ` Dan Williams
2023-06-07 1:06 ` Vikram Sethi
2023-06-07 15:12 ` Jonathan Cameron
2023-06-07 18:44 ` Vikram Sethi
2023-06-08 15:19 ` Jonathan Cameron
2023-06-08 18:41 ` Dan Williams
2024-03-27 7:10 ` Yuquan Wang
2024-03-27 7:18 ` Yuquan Wang
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=646e78c67ce17_33fb329432@dwillia2-xfh.jf.intel.com.notmuch \
--to=dan.j.williams@intel.com \
--cc=linux-cxl@vger.kernel.org \
--cc=y-goto@fujitsu.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