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 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 6948DC433E0 for ; Sun, 7 Feb 2021 22:26:16 +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 1483364DFD for ; Sun, 7 Feb 2021 22:26:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1483364DFD 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=jwKf/zPHr0JwfxePkto+URszsmkFn3SrpZ9j27IGmo4=; b=CJhKj5YyXAcLHVa+N48vnAYDi wECTvaTd5VfeWzgjo6W8UyC788RYib20iarYLVqAhsPmC/omMCoBWOCFlZR4LjWgEMofwLof/LR+o 80K6dZDz7o5s7hfqp6neX4FZfdfCEFDNsd7uMHqIFfKdgHhbO0zj2ljPjgsg7HwuIP+nR/1hJEtC1 ubo5iP4POueuI9aWpWmNOae7TKdp7ky58wj6cHHxbl5C946IRP2XEoOZYTE945Yp/7ULdUwI9tOVy A1ZSqtTflApn5KnkvB9qV6ocALzUCf1vDRlp23G5jYY3C6SKyus6Q6I9OnAgkT7B5ndsD3DrtSA5o /854kbjUg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l8sTy-0004a4-Ea; Sun, 07 Feb 2021 22:24:42 +0000 Received: from szxga01-in.huawei.com ([45.249.212.187]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1l8sTv-0004YV-UH for linux-arm-kernel@lists.infradead.org; Sun, 07 Feb 2021 22:24:41 +0000 Received: from DGGEMM404-HUB.china.huawei.com (unknown [172.30.72.54]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4DYkFH2dR4zY664; Mon, 8 Feb 2021 06:23:15 +0800 (CST) Received: from dggpemm100012.china.huawei.com (7.185.36.212) by DGGEMM404-HUB.china.huawei.com (10.3.20.212) with Microsoft SMTP Server (TLS) id 14.3.498.0; Mon, 8 Feb 2021 06:24:29 +0800 Received: from dggemi761-chm.china.huawei.com (10.1.198.147) by dggpemm100012.china.huawei.com (7.185.36.212) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2106.2; Mon, 8 Feb 2021 06:24:29 +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; Mon, 8 Feb 2021 06:24:29 +0800 From: "Song Bao Hua (Barry Song)" To: Matthew Wilcox , "Wangzhou (B)" 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/SrsWWMRpilf2UC1Pz29QqsBVqpMsX2AgACQE1A= Date: Sun, 7 Feb 2021 22:24:28 +0000 Message-ID: References: <1612685884-19514-1-git-send-email-wangzhou1@hisilicon.com> <1612685884-19514-2-git-send-email-wangzhou1@hisilicon.com> <20210207213409.GL308988@casper.infradead.org> In-Reply-To: <20210207213409.GL308988@casper.infradead.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.126.200.200] MIME-Version: 1.0 X-CFilter-Loop: Reflected X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210207_172440_465590_9F3C3830 X-CRM114-Status: GOOD ( 14.73 ) 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\)" , "jgg@ziepe.ca" , "linux-api@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "iommu@lists.linux-foundation.org" , 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: Matthew Wilcox [mailto:willy@infradead.org] > Sent: Monday, February 8, 2021 10:34 AM > To: Wangzhou (B) > Cc: 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; Song > Bao Hua (Barry Song) ; jgg@ziepe.ca; > 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 Sun, Feb 07, 2021 at 04:18:03PM +0800, Zhou Wang wrote: > > SVA(share virtual address) offers a way for device to share process virtual > > address space safely, which makes more convenient for user space device > > driver coding. However, IO page faults may happen when doing DMA > > operations. As the latency of IO page fault is relatively big, DMA > > performance will be affected severely when there are IO page faults. > > >From a long term view, DMA performance will be not stable. > > > > In high-performance I/O cases, accelerators might want to perform > > I/O on a memory without IO page faults which can result in dramatically > > increased latency. Current memory related APIs could not achieve this > > requirement, e.g. mlock can only avoid memory to swap to backup device, > > page migration can still trigger IO page fault. > > Well ... we have two requirements. The application wants to not take > page faults. The system wants to move the application to a different > NUMA node in order to optimise overall performance. Why should the > application's desires take precedence over the kernel's desires? And why > should it be done this way rather than by the sysadmin using numactl to > lock the application to a particular node? NUMA balancer is just one of many reasons for page migration. Even one simple alloc_pages() can cause memory migration in just single NUMA node or UMA system. The other reasons for page migration include but are not limited to: * memory move due to CMA * memory move due to huge pages creation Hardly we can ask users to disable the COMPACTION, CMA and Huge Page in the whole system. On the other hand, numactl doesn't always bind memory to single NUMA node, sometimes, while applications require many cpu, it could bind more than one memory node. Thanks Barry _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel