mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "xuxiaoyang (C)" <xuxiaoyang2@huawei.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: <linux-kernel@vger.kernel.org>, <kvm@vger.kernel.org>,
	<kwankhede@nvidia.com>, <wu.wubin@huawei.com>,
	<maoming.maoming@huawei.com>, <xieyingtai@huawei.com>,
	<lizhengui@huawei.com>, <wubinfeng@huawei.com>
Subject: Re: [PATCH] vfio iommu type1: Improve vfio_iommu_type1_pin_pages performance
Date: Thu, 12 Nov 2020 19:49:28 +0800	[thread overview]
Message-ID: <928f2c25-6a39-a9c0-64eb-05933fd46ce5@huawei.com> (raw)
In-Reply-To: <20201111085639.7235fb42@w520.home>

On 2020/11/11 23:56, Alex Williamson wrote:
> On Tue, 10 Nov 2020 21:42:33 +0800
> "xuxiaoyang (C)" <xuxiaoyang2@huawei.com> wrote:
> 
>> vfio_iommu_type1_pin_pages is very inefficient because
>> it is processed page by page when calling vfio_pin_page_external.
>> Added contiguous_vaddr_get_pfn to process continuous pages
>> to reduce the number of loops, thereby improving performance.
> 
> vfio_pin_pages() accepts an array of unrelated iova pfns and processes
> each to return the physical pfn.  AFAICT this proposal makes an
> unfounded and unverified assumption that the caller is asking for a
> range of contiguous iova pfns.  That's not the semantics of the call.
> This is wrong.  Thanks,
> 
> Alex
> 
> .
> 
Thank you for your reply.  Sorry that the comment is too simple
and not clear enough.
We did not change the external behavior of the function.  What we
have to do is to divide the iova pfn array into multiple continuous
ranges and optimize them.  For example, when the iova pfn array is
{1,5,6,7,9}, it will be divided into three groups {1}, {5,6,7}, {9}
for processing.  When processing {5,6,7}, the number of calls to
pin_user_pages_remote is reduced from 3 times to once.  The more
continuous the iova pfn array, the greater the performance improvement.
I see that most of the iova pfn arrays processed by callers are
continuous, such as pfn_array_pin, gvt_pin_guest_page.  For them,
performance will be improved.

Regards,
Xu

  reply	other threads:[~2020-11-12 11:49 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-10 13:42 xuxiaoyang (C)
2020-11-11 15:56 ` Alex Williamson
2020-11-12 11:49   ` xuxiaoyang (C) [this message]
2020-11-13 16:44 ` Alex Williamson
2020-11-16 13:47   ` xuxiaoyang (C)
2020-11-16 16:33     ` Alex Williamson
2020-11-17  3:31       ` xuxiaoyang (C)

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=928f2c25-6a39-a9c0-64eb-05933fd46ce5@huawei.com \
    --to=xuxiaoyang2@huawei.com \
    --cc=alex.williamson@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=kwankhede@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizhengui@huawei.com \
    --cc=maoming.maoming@huawei.com \
    --cc=wu.wubin@huawei.com \
    --cc=wubinfeng@huawei.com \
    --cc=xieyingtai@huawei.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

Powered by JetHome