Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp282699pxb; Thu, 12 Nov 2020 03:51:56 -0800 (PST) X-Google-Smtp-Source: ABdhPJwKurs3gVuIM/gjMKtOgMPj8535Lk2Cp5O1gYCDSdU/hSlG32G0YHO61nRpT0+9MHAwV7nS X-Received: by 2002:a17:906:31cb:: with SMTP id f11mr29566667ejf.142.1605181916337; Thu, 12 Nov 2020 03:51:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605181916; cv=none; d=google.com; s=arc-20160816; b=J+HJaiCxeZgxhaDMKnITET5LfH3OMBhWSJaxhiRcAfUxG8l2E4ROU3t9ErGGYpoiNw 9geqKEp/3lfzk5s0JdR6zmpxbsT7Jj5vjPPcFO2cNSeo6QEPMJCooiRet7A3wl0mQwF+ B9jr1GHE9VK3AndoCTpWIaMmD+z8t1fN23V+dRDfGpTXPhiV83lGnNhI/33PPurU5Lqb /C3yW40c72FE46aI3WXSF3OItlAif37r+u31yrVQ2RwFFckMCRAuGfHMVpD87QtG2NSb 9y9VYxxBznPzISkn/rtpdvkJZSkg1fJPAAzZoJWYhEHdtIoFx7H7rmvQN5AtsDdNUj9m 9Fdg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=AOGx/3CU7tBKa9wNX1zJFxXvFh0cEOfKVPfkiKqYoCg=; b=dsa8kEVSCYuhIRH9+HxLTnhReRb4n2BJzWklHWd4A52xtyLr3OXKgImxg6BWrHsVOj 95pzJQ1ozuNNIZo/P0pGUaThlJsbXc1QRwGLHGPMycYMAzdRR3FgMQ7Bt/XP7t0bsBXM cTj7ppT2X6e4oHG6/Qs8Qbup9BdYtKsRPYvanXtiKTXQf1/rZD/yKTkS44W0xCzYvYhp EnEgZ8OfVK2WeKx2D7QOb178K6VADaxWJv6c9jjA6dQdS9gAK6BAegECDDGRtsJ32QKC toD268ioMMkGsa0zEnph/pEId2Hw4PH+Nzgu0F5DvbbrK71oz2BWLFUaLSOgEqvzpwUP qXsw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id hs5si3710479ejc.718.2020.11.12.03.51.33; Thu, 12 Nov 2020 03:51:56 -0800 (PST) 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; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728245AbgKLLtl (ORCPT + 99 others); Thu, 12 Nov 2020 06:49:41 -0500 Received: from szxga01-in.huawei.com ([45.249.212.187]:2061 "EHLO szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728151AbgKLLtb (ORCPT ); Thu, 12 Nov 2020 06:49:31 -0500 Received: from dggeme753-chm.china.huawei.com (unknown [172.30.72.57]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4CX0Hn5NMjzVnBN; Thu, 12 Nov 2020 19:49:09 +0800 (CST) Received: from [10.174.184.120] (10.174.184.120) by dggeme753-chm.china.huawei.com (10.3.19.99) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Thu, 12 Nov 2020 19:49:28 +0800 Subject: Re: [PATCH] vfio iommu type1: Improve vfio_iommu_type1_pin_pages performance To: Alex Williamson CC: , , , , , , , References: <2553f102-de17-b23b-4cd8-fefaf2a04f24@huawei.com> <20201111085639.7235fb42@w520.home> From: "xuxiaoyang (C)" Message-ID: <928f2c25-6a39-a9c0-64eb-05933fd46ce5@huawei.com> Date: Thu, 12 Nov 2020 19:49:28 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.3.2 MIME-Version: 1.0 In-Reply-To: <20201111085639.7235fb42@w520.home> Content-Type: text/plain; charset="utf-8" Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.184.120] X-ClientProxiedBy: dggeme703-chm.china.huawei.com (10.1.199.99) To dggeme753-chm.china.huawei.com (10.3.19.99) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020/11/11 23:56, Alex Williamson wrote: > On Tue, 10 Nov 2020 21:42:33 +0800 > "xuxiaoyang (C)" 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