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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,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 65549C433E0 for ; Wed, 10 Feb 2021 21:39:19 +0000 (UTC) Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B7F3764EDF for ; Wed, 10 Feb 2021 21:39:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B7F3764EDF Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=hisilicon.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=iommu-bounces@lists.linux-foundation.org Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id 8D6C3874F7; Wed, 10 Feb 2021 21:39:18 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPpYMI3XyW1K; Wed, 10 Feb 2021 21:39:17 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by hemlock.osuosl.org (Postfix) with ESMTP id AFED2874F5; Wed, 10 Feb 2021 21:39:17 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 98002C0891; Wed, 10 Feb 2021 21:39:17 +0000 (UTC) Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id ACA17C013A for ; Wed, 10 Feb 2021 21:39:16 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 9933186A63 for ; Wed, 10 Feb 2021 21:39:16 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGQh5oaV+om4 for ; Wed, 10 Feb 2021 21:39:13 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by whitealder.osuosl.org (Postfix) with ESMTPS id 68C8086E97 for ; Wed, 10 Feb 2021 21:39:13 +0000 (UTC) Received: from DGGEMM402-HUB.china.huawei.com (unknown [172.30.72.55]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4DbY5Y0SHwzR9M9; Thu, 11 Feb 2021 05:37:53 +0800 (CST) Received: from dggpemm100011.china.huawei.com (7.185.36.112) by DGGEMM402-HUB.china.huawei.com (10.3.20.210) with Microsoft SMTP Server (TLS) id 14.3.498.0; Thu, 11 Feb 2021 05:39:09 +0800 Received: from dggemi761-chm.china.huawei.com (10.1.198.147) by dggpemm100011.china.huawei.com (7.185.36.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2106.2; Thu, 11 Feb 2021 05:39:09 +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; Thu, 11 Feb 2021 05:39:09 +0800 From: "Song Bao Hua (Barry Song)" To: Jason Gunthorpe Subject: RE: [RFC PATCH v3 1/2] mempinfd: Add new syscall to provide memory pin Thread-Topic: [RFC PATCH v3 1/2] mempinfd: Add new syscall to provide memory pin Thread-Index: AQHW/SrsWWMRpilf2UC1Pz29QqsBVqpNZGQAgACtCgCAAKKukP//jqmAgADcIzCAADaMgIABCrxAgADNm4CAALRckA== Date: Wed, 10 Feb 2021 21:39:09 +0000 Message-ID: <8a676b45ebaa49e8886f4bf9b762bb75@hisilicon.com> References: <1612685884-19514-1-git-send-email-wangzhou1@hisilicon.com> <1612685884-19514-2-git-send-email-wangzhou1@hisilicon.com> <20210208183348.GV4718@ziepe.ca> <0dca000a6cd34d8183062466ba7d6eaf@hisilicon.com> <20210208213023.GZ4718@ziepe.ca> <0868d209d7424942a46d1238674cf75d@hisilicon.com> <20210209135331.GF4718@ziepe.ca> <2527b4ac8df14fa1b427bef65dace719@hisilicon.com> <20210210180405.GP4718@ziepe.ca> In-Reply-To: <20210210180405.GP4718@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.201.223] MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "jean-philippe@linaro.org" , "kevin.tian@intel.com" , "chensihang \(A\)" , David Hildenbrand , "linux-api@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "iommu@lists.linux-foundation.org" , "linux-mm@kvack.org" , Alexander Viro , "gregkh@linuxfoundation.org" , "zhangfei.gao@linaro.org" , Andrew Morton , "Liguozhu \(Kenneth\)" , "linux-arm-kernel@lists.infradead.org" X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: iommu-bounces@lists.linux-foundation.org Sender: "iommu" > -----Original Message----- > From: Jason Gunthorpe [mailto:jgg@ziepe.ca] > Sent: Thursday, February 11, 2021 7:04 AM > To: Song Bao Hua (Barry Song) > Cc: David Hildenbrand ; Wangzhou (B) > ; linux-kernel@vger.kernel.org; > iommu@lists.linux-foundation.org; linux-mm@kvack.org; > linux-arm-kernel@lists.infradead.org; linux-api@vger.kernel.org; Andrew > Morton ; Alexander Viro ; > gregkh@linuxfoundation.org; kevin.tian@intel.com; jean-philippe@linaro.org; > eric.auger@redhat.com; Liguozhu (Kenneth) ; > zhangfei.gao@linaro.org; chensihang (A) > Subject: Re: [RFC PATCH v3 1/2] mempinfd: Add new syscall to provide memory > pin > > On Tue, Feb 09, 2021 at 10:22:47PM +0000, Song Bao Hua (Barry Song) wrote: > > > The problem is that SVA declares we can use any memory of a process > > to do I/O. And in real scenarios, we are unable to customize most > > applications to make them use the pool. So we are looking for some > > extension generically for applications such as Nginx, Ceph. > > But those applications will suffer jitter even if their are using CPU > to do the same work. I fail to see why adding an accelerator suddenly > means the application owner will care about jitter introduced by > migration/etc. The only point for this is that when migration occurs on the accelerator, the impact/jitter is much bigger than it does on CPU. Then the accelerator might be unhelpful. > > Again in proper SVA it should be quite unlikely to take a fault caused > by something like migration, on the same likelyhood as the CPU. If > things are faulting so much this is a problem then I think it is a > system level problem with doing too much page motion. My point is that single one SVA application shouldn't require system to make global changes, such as disabling numa balancing, disabling THP, to decrease page fault frequency by affecting other applications. Anyway, guys are in lunar new year. Hopefully, we are getting more real benchmark data afterwards to make the discussion more targeted. > > Jason Thanks Barry _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu