Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: =?UTF-8?B?UmU6IOetlOWkjTog562U5aSNOiBbUEFUQ0ggVjJdIHZmaW8gZG1hX21h?=
 =?UTF-8?Q?p/unmap=3a_optimized_for_hugetlbfs_pages?=
To:     Peter Xu <peterx@redhat.com>,
        "Maoming (maoming, Cloud Infrastructure Service Product Dept.)" 
        <maoming.maoming@huawei.com>
Cc:     "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
        "alex.williamson@redhat.com" <alex.williamson@redhat.com>,
        "cohuck@redhat.com" <cohuck@redhat.com>,
        "Zhoujian (jay)" <jianjay.zhou@huawei.com>,
        "Huangweidong (C)" <weidong.huang@huawei.com>,
        "aarcange@redhat.com" <aarcange@redhat.com>,
        wangyunjian <wangyunjian@huawei.com>
References: <20200814023729.2270-1-maoming.maoming@huawei.com>
 <20200825205907.GB8235@xz-x1>
 <8B561EC9A4D13649A62CF60D3A8E8CB28C2D9ABB@dggeml524-mbx.china.huawei.com>
 <20200826151509.GD8235@xz-x1>
 <8B561EC9A4D13649A62CF60D3A8E8CB28C2DBE7A@dggeml524-mbx.china.huawei.com>
 <20200828142400.GA3197@xz-x1>
From:   Jason Wang <jasowang@redhat.com>
Message-ID: <a07f4db3-7680-14ac-dd1e-6851e051aa4e@redhat.com>
Date:   Tue, 1 Sep 2020 10:40:29 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <20200828142400.GA3197@xz-x1>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


On 2020/8/28 下午10:24, Peter Xu wrote:
> On Fri, Aug 28, 2020 at 09:23:08AM +0000, Maoming (maoming, Cloud Infrastructure Service Product Dept.) wrote:
>> In hugetlb_put_pfn(), I delete unpin_user_pages_dirty_lock() and use some simple code to put hugetlb pages.
>> Is this right?
> I think we should still use the APIs because of the the same reason.  However
> again I don't know the performance impact of that to your patch, but I still
> think that could be done inside gup itself when needed (e.g., a special path
> for hugetlbfs for [un]pinning continuous pages; though if that's the case that
> could be something to be discussed on -mm then as a separate patch, imho).
>
> Thanks,


+1, we should make this as a generic optimization instead of VFIO 
specific consider there're a lot of GUP users.

Thanks