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=-4.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,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 D4501C433E0 for ; Tue, 9 Feb 2021 22:24:13 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 84BED64DDF for ; Tue, 9 Feb 2021 22:24:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 84BED64DDF Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=hisilicon.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:In-Reply-To:References:Message-ID:Date: Subject:To:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=96ubcJKU0Q1uQq52pZYW3m+rHlVF6Y3/y967uPG7usA=; b=a4cfeLXJq2QkqV6E9G+jsO3bM Ep2vkhH1ue/gA/SFojPa0tA4Hmb4MW8mqGmy2YlgXyN7sOzkmIGphgLxXFRNgMYb2Gzz39soA65AD KLmo69JZv32NfKvHN5jf8Hz+yTMuEa9yHOQs5Ne/kLPcnyjo07/4vban0uMjoA/fVQ7WLB30laqvq 9X3CMwcwpoCMWWtmLnQOPVaC2oukCl/fCxU1x0jICEUtKw5XIQ3LZtzMCvTxelO5Q3Hub4h5wPz8G 8LGU4QbcqllGgvila50RS96a+yAzVA7GtSQa1AkwfAVto8Dlx2x8a+eu5w0uaZZTglOvS5XmdEb3O fiJkHhk0A==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l9bPN-00008M-M8; Tue, 09 Feb 2021 22:22:57 +0000 Received: from szxga03-in.huawei.com ([45.249.212.189]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1l9bPK-00006Z-Lt for linux-arm-kernel@lists.infradead.org; Tue, 09 Feb 2021 22:22:56 +0000 Received: from DGGEMM401-HUB.china.huawei.com (unknown [172.30.72.54]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4DZy5p3j1qz5KDt; Wed, 10 Feb 2021 06:21:02 +0800 (CST) Received: from dggpemm500011.china.huawei.com (7.185.36.110) by DGGEMM401-HUB.china.huawei.com (10.3.20.209) with Microsoft SMTP Server (TLS) id 14.3.498.0; Wed, 10 Feb 2021 06:22:48 +0800 Received: from dggemi761-chm.china.huawei.com (10.1.198.147) by dggpemm500011.china.huawei.com (7.185.36.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2106.2; Wed, 10 Feb 2021 06:22:47 +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; Wed, 10 Feb 2021 06:22:47 +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//jqmAgADcIzCAADaMgIABCrxA Date: Tue, 9 Feb 2021 22:22:47 +0000 Message-ID: <2527b4ac8df14fa1b427bef65dace719@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> In-Reply-To: <20210209135331.GF4718@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.202.77] MIME-Version: 1.0 X-CFilter-Loop: Reflected X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210209_172255_182103_147E7AFA X-CRM114-Status: GOOD ( 16.55 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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" , "Wangzhou \(B\)" , Alexander Viro , "eric.auger@redhat.com" , "gregkh@linuxfoundation.org" , "zhangfei.gao@linaro.org" , Andrew Morton , "Liguozhu \(Kenneth\)" , "linux-arm-kernel@lists.infradead.org" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org > -----Original Message----- > From: Jason Gunthorpe [mailto:jgg@ziepe.ca] > Sent: Wednesday, February 10, 2021 2:54 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 03:01:42AM +0000, Song Bao Hua (Barry Song) wrote: > > > On the other hand, wouldn't it be the benefit of hardware accelerators > > to have a lower and more stable latency zip/encryption than CPU? > > No, I don't think so. Fortunately or unfortunately, I think my people have this target to have a lower-latency and more stable zip/encryption by using accelerators, otherwise, they are going to use CPU directly if there is no advantage of accelerators. > > If this is an important problem then it should apply equally to CPU > and IO jitter. > > Honestly I find the idea that occasional migration jitters CPU and DMA > to not be very compelling. Such specialized applications should > allocate special pages to avoid this, not adding an API to be able to > lock down any page That is exactly what we have done to provide a hugeTLB pool so that applications can allocate memory from this pool. +-------------------------------------------+ | | |applications using accelerators | +-------------------------------------------+ alloc from pool free to pool + ++ | | | | | | | | | | | | | | +----------+-----------------------+---------+ | | | | | HugeTLB memory pool | | | | | +--------------------------------------------+ 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. I am also thinking about leveraging vm.compact_unevictable_allowed which David suggested and making an extension on it, for example, permit users to disable compaction and numa balancing on unevictable pages of SVA process, which might be a smaller deal. > > Jason Thanks Barry _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel