From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,PDS_BAD_THREAD_QP_64, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8BAACC433E0 for ; Mon, 25 Jan 2021 23:35:30 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id DE95D22AAA for ; Mon, 25 Jan 2021 23:35:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DE95D22AAA Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=hisilicon.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 5B76B8D005F; Mon, 25 Jan 2021 18:35:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5681E8D0059; Mon, 25 Jan 2021 18:35:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 47E2F8D005F; Mon, 25 Jan 2021 18:35:29 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0038.hostedemail.com [216.40.44.38]) by kanga.kvack.org (Postfix) with ESMTP id 3198E8D0059 for ; Mon, 25 Jan 2021 18:35:29 -0500 (EST) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id E60B21EE6 for ; Mon, 25 Jan 2021 23:35:28 +0000 (UTC) X-FDA: 77745906336.16.food82_460175b27589 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin16.hostedemail.com (Postfix) with ESMTP id AFB41100E6917 for ; Mon, 25 Jan 2021 23:35:28 +0000 (UTC) X-HE-Tag: food82_460175b27589 X-Filterd-Recvd-Size: 4410 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by imf14.hostedemail.com (Postfix) with ESMTP for ; Mon, 25 Jan 2021 23:35:26 +0000 (UTC) Received: from DGGEMM404-HUB.china.huawei.com (unknown [172.30.72.55]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4DPmRG2ZPfzR7MJ; Tue, 26 Jan 2021 07:34:18 +0800 (CST) Received: from dggpemm100010.china.huawei.com (7.185.36.24) by DGGEMM404-HUB.china.huawei.com (10.3.20.212) with Microsoft SMTP Server (TLS) id 14.3.498.0; Tue, 26 Jan 2021 07:35:23 +0800 Received: from dggemi761-chm.china.huawei.com (10.1.198.147) by dggpemm100010.china.huawei.com (7.185.36.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2106.2; Tue, 26 Jan 2021 07:35:22 +0800 Received: from dggemi761-chm.china.huawei.com ([10.9.49.202]) by dggemi761-chm.china.huawei.com ([10.9.49.202]) with mapi id 15.01.2106.006; Tue, 26 Jan 2021 07:35:22 +0800 From: "Song Bao Hua (Barry Song)" To: Jason Gunthorpe CC: "Wangzhou (B)" , Greg Kroah-Hartman , Arnd Bergmann , Zhangfei Gao , "linux-accelerators@lists.ozlabs.org" , "linux-kernel@vger.kernel.org" , "iommu@lists.linux-foundation.org" , "linux-mm@kvack.org" , "Liguozhu (Kenneth)" , "chensihang (A)" Subject: RE: [RFC PATCH v2] uacce: Add uacce_ctrl misc device Thread-Topic: [RFC PATCH v2] uacce: Add uacce_ctrl misc device Thread-Index: AQHW8vWniUnMS+RFOU2UJJCa8sDlvKo39q+AgADtcaD//5AFgIAAh9tQ Date: Mon, 25 Jan 2021 23:35:22 +0000 Message-ID: <5f64a68042c64f37b5cba74028bd2189@hisilicon.com> References: <1611563696-235269-1-git-send-email-wangzhou1@hisilicon.com> <20210125154717.GW4605@ziepe.ca> <96b655ade2534a65974a378bb68383ee@hisilicon.com> <20210125231619.GY4605@ziepe.ca> In-Reply-To: <20210125231619.GY4605@ziepe.ca> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.126.203.227] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: > -----Original Message----- > From: owner-linux-mm@kvack.org [mailto:owner-linux-mm@kvack.org] On Behal= f Of > Jason Gunthorpe > Sent: Tuesday, January 26, 2021 12:16 PM > To: Song Bao Hua (Barry Song) > Cc: Wangzhou (B) ; Greg Kroah-Hartman > ; Arnd Bergmann ; Zhangfei Gao > ; linux-accelerators@lists.ozlabs.org; > linux-kernel@vger.kernel.org; iommu@lists.linux-foundation.org; > linux-mm@kvack.org; Liguozhu (Kenneth) ; chensiha= ng > (A) > Subject: Re: [RFC PATCH v2] uacce: Add uacce_ctrl misc device >=20 > On Mon, Jan 25, 2021 at 10:21:14PM +0000, Song Bao Hua (Barry Song) wrote= : > > mlock, while certainly be able to prevent swapping out, it won't > > be able to stop page moving due to: > > * memory compaction in alloc_pages() > > * making huge pages > > * numa balance > > * memory compaction in CMA >=20 > Enabling those things is a major reason to have SVA device in the > first place, providing a SW API to turn it all off seems like the > wrong direction. I wouldn't say this is a major reason to have SVA. If we read the history of SVA and papers, people would think easy programming due to data struct sharing between cpu and device, and process space isolation in device would be the major reasons for SVA. SVA also declares it supports zero-copy while zero-copy doesn't necessarily depend on SVA. Page migration and I/O page fault overhead, on the other hand, would probably be the major problems which block SVA becoming a=20 high-performance and more popular solution. >=20 > If the device doesn't want to use SVA then don't use it, use normal > DMA pinning like everything else. >=20 If we disable SVA, we won't get the benefits of SVA on address sharing, and process space isolation. > Jason Thanks Barry