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,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 47EACC433DB for ; Sun, 7 Feb 2021 22:02:41 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CEC3A64DB2 for ; Sun, 7 Feb 2021 22:02:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CEC3A64DB2 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=amacapital.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 4246C6B0006; Sun, 7 Feb 2021 17:02:40 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3D5106B006C; Sun, 7 Feb 2021 17:02:40 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2EB6F6B006E; Sun, 7 Feb 2021 17:02:40 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0221.hostedemail.com [216.40.44.221]) by kanga.kvack.org (Postfix) with ESMTP id 151506B0006 for ; Sun, 7 Feb 2021 17:02:40 -0500 (EST) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id C3F9E8249980 for ; Sun, 7 Feb 2021 22:02:39 +0000 (UTC) X-FDA: 77792846838.06.toe10_4a123eb275f9 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin06.hostedemail.com (Postfix) with ESMTP id A395D1003A868 for ; Sun, 7 Feb 2021 22:02:39 +0000 (UTC) X-HE-Tag: toe10_4a123eb275f9 X-Filterd-Recvd-Size: 5390 Received: from mail-pl1-f180.google.com (mail-pl1-f180.google.com [209.85.214.180]) by imf18.hostedemail.com (Postfix) with ESMTP for ; Sun, 7 Feb 2021 22:02:39 +0000 (UTC) Received: by mail-pl1-f180.google.com with SMTP id e12so6792092pls.4 for ; Sun, 07 Feb 2021 14:02:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=rF9rOEV9Q8WVIOH0rqIWO7EqANQSyBnp1ft+vyl9KF0=; b=QANXs0Ex159+byJKUEaE28kl3Xh1NJ9WQlAArBMiqR/LE0uHG9IpHhfqWrVmJbho7R zP1u0EqWhELbEmtTGccuSGqB1fhJqbp8L6ZAFLx9BsWQEpn7+9fUeq7ZlknoiHHfRYsV yCiSNhT/oz/MSrVIf+6C3avuFCznOmT2MIzTiHTudXkJ3md/uaNKYTp7OcY+zyFWUdx3 t2hI93ykFPrRg/ziGbbX6FfZAddsJEzERu6Jadvk5KI3v/9ZrpWsV/zrUDO5Y59dlxde zHUljpHpBinHt9TpnJyq7p6CZXtVOCBYq6uXD8Si3ujOPNxK8fpJ1Q0naopg0iRuSxBm +jGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=rF9rOEV9Q8WVIOH0rqIWO7EqANQSyBnp1ft+vyl9KF0=; b=IHhFEsszFBP5lWTQUOKnPW/vZBZqA+wXu6D4x73CH25zEQHTgejj2zsTHOX/Ctc8Fw plZEDIkMdQ/9hhqTGvbOQu2GjuYsCMvsE/JoSztMHkLTn4YEM1LFraREW8HIi17bpcee nuzp62uqFhvWAePQRCxsRkrDOEyKZlJB9oGli4ueQ1LmSZkb/IAQsA7ItgXEg7d+24rD MfMLB9Gca0IbgZlqe1WV04U3okFzWOeUHWQx67f8UmLtRf0YweraChkVwcN+zK2nLzxQ SXhoqKBcqXscijRTWFtD4s00ovTLkTKaZ8TC+uMv5Zqcfrb9IFMY1uoLZvaaLDmuJ5ue FSqw== X-Gm-Message-State: AOAM532T7bVo9OyLfzVVoqy+GgYWVA4LGJRThzQcp6RmdPd77QJqNySW DZIjPOIHFFiEtCsnfVm6ap5zrg== X-Google-Smtp-Source: ABdhPJzNR1bzv/JQhWJTt0CBbMKbJVt9xR9k8FE58XkDiaugfM9e0sPAPw9t+dZ9eAqufWWfnMqn+g== X-Received: by 2002:a17:90a:184:: with SMTP id 4mr13919868pjc.87.1612735358046; Sun, 07 Feb 2021 14:02:38 -0800 (PST) Received: from ?IPv6:2601:646:c200:1ef2:8e8:e217:43e7:e032? ([2601:646:c200:1ef2:8e8:e217:43e7:e032]) by smtp.gmail.com with ESMTPSA id i25sm16435713pgb.33.2021.02.07.14.02.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 07 Feb 2021 14:02:37 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Andy Lutomirski Mime-Version: 1.0 (1.0) Subject: Re: [RFC PATCH v3 1/2] mempinfd: Add new syscall to provide memory pin Date: Sun, 7 Feb 2021 14:02:36 -0800 Message-Id: References: <1612685884-19514-2-git-send-email-wangzhou1@hisilicon.com> 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@hisilicon.com, jgg@ziepe.ca, kevin.tian@intel.com, jean-philippe@linaro.org, eric.auger@redhat.com, liguozhu@hisilicon.com, zhangfei.gao@linaro.org, Sihang Chen In-Reply-To: <1612685884-19514-2-git-send-email-wangzhou1@hisilicon.com> To: Zhou Wang X-Mailer: iPhone Mail (18D52) 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: > On Feb 7, 2021, at 12:31 AM, Zhou Wang wrote: >=20 > =EF=BB=BFSVA(share virtual address) offers a way for device to share proce= ss 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. > =46rom a long term view, DMA performance will be not stable. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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? Userfaultfd is an fd because one program controls another. Is mempinfd like= this?=