Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp423024pxb; Tue, 9 Feb 2021 04:02:35 -0800 (PST) X-Google-Smtp-Source: ABdhPJxqnQYrlsE/kqmlh8faXNsbmW81n/7SVIyDkZKGsShMKWes6zVEtZP2Mb3ZSDGk7VPNtkKK X-Received: by 2002:a17:906:3603:: with SMTP id q3mr16720290ejb.201.1612872155267; Tue, 09 Feb 2021 04:02:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612872155; cv=none; d=google.com; s=arc-20160816; b=Dc9SwBsWWKRpKzt2mhnz9GZXWOIGJN1uiSBZUinrD/mXvFTN20Ap1vOucsJbODhr3E 2IwvCU41KxkUaIc4FAk3S5DxaFOyg6ZYg5bMmg5D6k8y9PBrXFCTbH59kzYY8lK49rN8 8Vf7l3vYArHHDc2WWpCcuIR8PBk1SFMnE6zJByeKqfzwiNt3OA8RtFcQiQFk3DHV4S93 Tt+PE93KiUo7gr+MZBhWuNdihhlhw+/nXQkZMqiUpfleq6agD1P4KtKSl4ZqyX36kanL y2k52zeYRzGJIQTuGWp007oAIGT7a7lue3aflZyDQBI+jBxM+sFy3H4jSEiimQqzQc3I iqSg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:cc:references:to :subject; bh=YB1vRUoT4W3PJTz1VkSvAtc7cHFqe6Wq3mELFktspSA=; b=Lle7OJHVN6qu9RcFOe53kGYvUn4HqxHMIC5JXn1wWSibJWFjdoDyA8d/SS+RoJsF+k jreEUtoSZTPt8mAdIsnZ/KDl04XGKFd/6/kWF+sjKEKvx4QBjaV4CU/zXuKr/X3Rykoz XgwW1XKvNduLN1O86hrRVC0PX7jVDi3YKmUh4oGZsT64loP8IfF6xwwJbWCWpTHB9+BU Bw9SqrKEasymkqCg4DcZXaUa1zdkSW3qALT460/D5PMBXMk1/s1L4PLmirkCYpZYYb4L a5H/11j5a9kj61WobGEGUCOD2hizKA80NVGMXwgGMYuT39Wv7+fKDP82LG/eXH5vv02V L1vg== 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 c18si14414128ede.4.2021.02.09.04.02.01; Tue, 09 Feb 2021 04:02:35 -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 S229743AbhBIL7W (ORCPT + 99 others); Tue, 9 Feb 2021 06:59:22 -0500 Received: from szxga07-in.huawei.com ([45.249.212.35]:12884 "EHLO szxga07-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229993AbhBIL7G (ORCPT ); Tue, 9 Feb 2021 06:59:06 -0500 Received: from DGGEMS411-HUB.china.huawei.com (unknown [172.30.72.60]) by szxga07-in.huawei.com (SkyGuard) with ESMTP id 4DZhFm2lTgz7hpn; Tue, 9 Feb 2021 19:57:00 +0800 (CST) Received: from [127.0.0.1] (10.40.188.87) by DGGEMS411-HUB.china.huawei.com (10.3.19.211) with Microsoft SMTP Server id 14.3.498.0; Tue, 9 Feb 2021 19:58:15 +0800 Subject: Re: [RFC PATCH v3 1/2] mempinfd: Add new syscall to provide memory pin To: Greg KH References: <1612685884-19514-2-git-send-email-wangzhou1@hisilicon.com> <2e6cf99f-beb6-9bef-1316-5e58fb0aa86e@hisilicon.com> CC: Andy Lutomirski , , , , , , "Andrew Morton" , Alexander Viro , , , , , , , , Sihang Chen From: Zhou Wang Message-ID: Date: Tue, 9 Feb 2021 19:58:15 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.40.188.87] X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2021/2/9 17:37, Greg KH wrote: > On Tue, Feb 09, 2021 at 05:17:46PM +0800, Zhou Wang wrote: >> On 2021/2/8 6:02, Andy Lutomirski wrote: >>> >>> >>>> On Feb 7, 2021, at 12:31 AM, 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. >>>> >>>> Various drivers working under traditional non-SVA mode are using >>>> their own specific ioctl to do pin. Such ioctl can be seen in v4l2, >>>> gpu, infiniband, media, vfio, etc. Drivers are usually doing dma >>>> mapping while doing pin. >>>> >>>> But, in SVA mode, pin could be a common need which isn't necessarily >>>> bound with any drivers, and neither is dma mapping needed by drivers >>>> since devices are using the virtual address of CPU. Thus, It is better >>>> to introduce a new common syscall for it. >>>> >>>> This patch leverages the design of userfaultfd and adds mempinfd for pin >>>> to avoid messing up mm_struct. A fd will be got by mempinfd, then user >>>> space can do pin/unpin pages by ioctls of this fd, all pinned pages under >>>> one file will be unpinned in file release process. Like pin page cases in >>>> other places, can_do_mlock is used to check permission and input >>>> parameters. >>> >>> >>> Can you document what the syscall does? >> >> Will add related document in Documentation/vm. > > A manpage is always good, and will be required eventually :) manpage is maintained in another repo. Do you mean add a manpage patch in this series? Best, Zhou > > thanks, > > greg k-h > > . >