[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [PATCH v5 5/7] migration/multifd: implement initialization of qpl co
From: |
Liu, Yuan1 |
Subject: |
RE: [PATCH v5 5/7] migration/multifd: implement initialization of qpl compression |
Date: |
Thu, 21 Mar 2024 01:37:36 +0000 |
> -----Original Message-----
> From: Peter Xu <peterx@redhat.com>
> Sent: Thursday, March 21, 2024 4:32 AM
> To: Liu, Yuan1 <yuan1.liu@intel.com>
> Cc: Daniel P. Berrangé <berrange@redhat.com>; farosas@suse.de; qemu-
> devel@nongnu.org; hao.xiang@bytedance.com; bryan.zhang@bytedance.com; Zou,
> Nanhai <nanhai.zou@intel.com>
> Subject: Re: [PATCH v5 5/7] migration/multifd: implement initialization of
> qpl compression
>
> On Wed, Mar 20, 2024 at 04:23:01PM +0000, Liu, Yuan1 wrote:
> > let me explain here, during the decompression operation of IAA, the
> > decompressed data can be directly output to the virtual address of the
> > guest memory by IAA hardware. It can avoid copying the decompressed
> data
> > to guest memory by CPU.
>
> I see.
>
> > Without -mem-prealloc, all the guest memory is not populated, and IAA
> > hardware needs to trigger I/O page fault first and then output the
> > decompressed data to the guest memory region. Besides that, CPU page
> > faults will also trigger IOTLB flush operation when IAA devices use SVM.
>
> Oh so the IAA hardware already can use CPU pgtables? Nice..
>
> Why IOTLB flush is needed? AFAIU we're only installing new pages, the
> request can either come from a CPU access or a DMA. In all cases there
> should have no tearing down of an old page. Isn't an iotlb flush only
> needed if a tear down happens?
As far as I know, IAA hardware uses SVM technology to use the CPU's page table
for address translation (IOMMU scalable mode directly accesses the CPU page
table).
Therefore, when the CPU page table changes, the device's Invalidation operation
needs
to be triggered to update the IOMMU and the device's cache.
My current kernel version is mainline 6.2. The issue I see is as follows:
--Handle_mm_fault
|
-- wp_page_copy
|
-- mmu_notifier_invalidate_range
|
-- intel_invalidate_rage
|
-- qi_flush_piotlb
-- qi_flush_dev_iotlb_pasid
> > Due to the inability to quickly resolve a large number of IO page faults
> > and IOTLB flushes, the decompression throughput of the IAA device will
> > decrease significantly.
>
> --
> Peter Xu
- Re: [PATCH v5 2/7] migration/multifd: put IOV initialization into compression method, (continued)
- [PATCH v5 5/7] migration/multifd: implement initialization of qpl compression, Yuan Liu, 2024/03/20
- Re: [PATCH v5 5/7] migration/multifd: implement initialization of qpl compression, Daniel P . Berrangé, 2024/03/20
- Re: [PATCH v5 5/7] migration/multifd: implement initialization of qpl compression, Peter Xu, 2024/03/20
- RE: [PATCH v5 5/7] migration/multifd: implement initialization of qpl compression, Liu, Yuan1, 2024/03/20
- Re: [PATCH v5 5/7] migration/multifd: implement initialization of qpl compression, Peter Xu, 2024/03/20
- RE: [PATCH v5 5/7] migration/multifd: implement initialization of qpl compression,
Liu, Yuan1 <=
- Re: [PATCH v5 5/7] migration/multifd: implement initialization of qpl compression, Peter Xu, 2024/03/21
- RE: [PATCH v5 5/7] migration/multifd: implement initialization of qpl compression, Liu, Yuan1, 2024/03/21
- RE: [PATCH v5 5/7] migration/multifd: implement initialization of qpl compression, Liu, Yuan1, 2024/03/22
- Re: [PATCH v5 5/7] migration/multifd: implement initialization of qpl compression, Peter Xu, 2024/03/22
- Re: [PATCH v5 5/7] migration/multifd: implement initialization of qpl compression, Peter Xu, 2024/03/27
- RE: [PATCH v5 5/7] migration/multifd: implement initialization of qpl compression, Liu, Yuan1, 2024/03/27
- Re: [PATCH v5 5/7] migration/multifd: implement initialization of qpl compression, Peter Xu, 2024/03/28
- RE: [PATCH v5 5/7] migration/multifd: implement initialization of qpl compression, Liu, Yuan1, 2024/03/28
[PATCH v5 1/7] docs/migration: add qpl compression feature, Yuan Liu, 2024/03/20