From: David Hildenbrand <david@redhat.com>
To: Gregory Price <gregory.price@memverge.com>
Cc: "Huang, Ying" <ying.huang@intel.com>,
Dragan Stancevic <dragan@stancevic.com>,
lsf-pc@lists.linux-foundation.org, nil-migration@lists.linux.dev,
linux-cxl@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [LSF/MM/BPF TOPIC] BoF VM live migration over CXL memory
Date: Wed, 12 Apr 2023 17:50:55 +0200 [thread overview]
Message-ID: <efe5dad7-8e58-b416-8108-bb692c726302@redhat.com> (raw)
In-Reply-To: <ZDbNoNN0nkzn4xe6@memverge.com>
On 12.04.23 17:26, Gregory Price wrote:
> On Wed, Apr 12, 2023 at 10:38:04AM +0200, David Hildenbrand wrote:
>> On 12.04.23 04:54, Huang, Ying wrote:
>>> Gregory Price <gregory.price@memverge.com> writes:
>>>
>>>> On Tue, Apr 11, 2023 at 02:37:50PM +0800, Huang, Ying wrote:
>>>>> Gregory Price <gregory.price@memverge.com> writes:
>>>>>
>>>>> [snip]
>>>>>
>>>>>> 2. During the migration process, the memory needs to be forced not to be
>>>>>> migrated to another node by other means (tiering software, swap,
>>>>>> etc). The obvious way of doing this would be to migrate and
>>>>>> temporarily pin the page... but going back to problem #1 we see that
>>>>>> ZONE_MOVABLE and Pinning are mutually exclusive. So that's
>>>>>> troublesome.
>>>>>
>>>>> Can we use memory policy (cpusets, mbind(), set_mempolicy(), etc.) to
>>>>> avoid move pages out of CXL.mem node? Now, there are gaps in tiering,
>>>>> but I think it is fixable.
>>>>>
>>>>> Best Regards,
>>>>> Huang, Ying
>>>>>
>>>>> [snip]
>>>>
>>>> That feels like a hack/bodge rather than a proper solution to me.
>>>>
>>>> Maybe this is an affirmative argument for the creation of an EXMEM
>>>> zone.
>>>
>>> Let's start with requirements. What is the requirements for a new zone
>>> type?
>>
>> I'm stills scratching my head regarding this. I keep hearing all different
>> kind of statements that just add more confusions "we want it to be
>> hotunpluggable" "we want to allow for long-term pinning memory" "but we
>> still want it to be movable" "we want to place some unmovable allocations on
>> it". Huh?
>>
>> Just to clarify: ZONE_MOVABLE allows for pinning. It just doesn't allow for
>> long-term pinning of memory.
>>
>
> I apologize for the confusion, this is my fault. I had assumed that
> since dax regions can't be pinned, subsequent nodes backed by a dax
> device could not be pinned. In testing this, this is not the case.
>
> Re: long-term pinning, can you be more explicit as to what is considered
> long-term? Minutes? hours? days? etc
long-term: possibly forever, controlled by user space. In practice,
anything longer than ~10 seconds ( best guess :) ). There can be
long-term pinnings that are of very short duration, we just don't know
what user space is up to and when it will decide to unpin.
Assume user space requests to trigger read/write of a user space page to
a file: the page is pinned, DMA is started, once DMA completes the page
is unpinned. Short-term. User space does not control how long the page
remains pinned.
In contrast:
Example #1: mapping VM guest memory into an IOMMU using vfio for PCI
passthrough requires pinning the pages. Until user space decides to
unmap the pages from the IOMMU, the pages will remain pinned. -> long-term
Example #2: mapping a user space address range into an IOMMU to
repeatedly perform RDMA using that address range requires pinning the
pages. Until user space decides to unregister that range, the pages
remain pinned. -> long-term
Example #3: registering a user space address range with io_uring as a
fixed buffer, such that io_uring OPS can avoid the page table walks by
simply using the pinned pages that were looked up once. As long as the
fixed buffer remains registered, the pages stay pinned. -> long-term
--
Thanks,
David / dhildenb
next prev parent reply other threads:[~2023-04-12 15:51 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-07 21:05 [LSF/MM/BPF TOPIC] BoF VM live migration over CXL memory Dragan Stancevic
2023-04-07 22:23 ` James Houghton
2023-04-07 23:17 ` David Rientjes
2023-04-08 1:33 ` Dragan Stancevic
2023-04-08 16:24 ` Dragan Stancevic
2023-04-08 0:05 ` Gregory Price
2023-04-11 0:56 ` Dragan Stancevic
2023-04-11 1:48 ` Gregory Price
2023-04-14 3:32 ` Dragan Stancevic
2023-04-14 13:16 ` [LSF/MM/BPF TOPIC] BoF VM live migration over CXL memory Jonathan Cameron
2023-04-11 6:37 ` [LSF/MM/BPF TOPIC] BoF VM live migration over CXL memory Huang, Ying
2023-04-11 15:36 ` Gregory Price
2023-04-12 2:54 ` Huang, Ying
2023-04-12 8:38 ` David Hildenbrand
2023-04-12 15:15 ` James Bottomley
2023-05-03 23:42 ` Dragan Stancevic
2023-04-12 15:26 ` Gregory Price
2023-04-12 15:50 ` David Hildenbrand [this message]
2023-04-12 16:34 ` Gregory Price
2023-04-14 4:16 ` Dragan Stancevic
2023-04-14 3:33 ` Dragan Stancevic
2023-04-14 5:35 ` Huang, Ying
2023-04-09 17:40 ` Shreyas Shah
2023-04-11 1:08 ` Dragan Stancevic
2023-04-11 1:17 ` Shreyas Shah
2023-04-11 1:32 ` Dragan Stancevic
2023-04-11 4:33 ` Shreyas Shah
2023-04-14 3:26 ` Dragan Stancevic
2023-04-11 18:00 ` Dave Hansen
2023-05-01 23:49 ` Dragan Stancevic
2023-04-11 18:16 ` RAGHU H
2023-05-09 15:08 ` Dragan Stancevic
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=efe5dad7-8e58-b416-8108-bb692c726302@redhat.com \
--to=david@redhat.com \
--cc=dragan@stancevic.com \
--cc=gregory.price@memverge.com \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=nil-migration@lists.linux.dev \
--cc=ying.huang@intel.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).