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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 92A02C433F5 for ; Tue, 1 Mar 2022 06:41:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2C3AB8D0003; Tue, 1 Mar 2022 01:41:11 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 272F48D0001; Tue, 1 Mar 2022 01:41:11 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 162588D0003; Tue, 1 Mar 2022 01:41:11 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0249.hostedemail.com [216.40.44.249]) by kanga.kvack.org (Postfix) with ESMTP id 08ECD8D0001 for ; Tue, 1 Mar 2022 01:41:11 -0500 (EST) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id A4A178249980 for ; Tue, 1 Mar 2022 06:41:10 +0000 (UTC) X-FDA: 79194870300.16.A448B1B Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by imf21.hostedemail.com (Postfix) with ESMTP id 153971C000D for ; Tue, 1 Mar 2022 06:41:09 +0000 (UTC) Received: from cwcc.thunk.org (pool-108-7-220-252.bstnma.fios.verizon.net [108.7.220.252]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 2216f2HF022120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 1 Mar 2022 01:41:03 -0500 Received: by cwcc.thunk.org (Postfix, from userid 15806) id 646DC15C0038; Tue, 1 Mar 2022 01:41:02 -0500 (EST) Date: Tue, 1 Mar 2022 01:41:02 -0500 From: "Theodore Ts'o" To: John Hubbard Cc: lsf-pc@lists.linux-foundation.org, Dave Chinner , Jan Kara , Christoph Hellwig , Jason Gary Gunthorpe , Chaitanya Kulkarni , Matthew Wilcox , Linux-MM , linux-fsdevel , "linux-block@vger.kernel.org" Subject: Re: [LSF/MM/BPF TOPIC] FOLL_PIN + file systems Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 153971C000D X-Stat-Signature: 5wjz7qnfubc7i4q7zoyb6xdszpeuiyay X-Rspam-User: Authentication-Results: imf21.hostedemail.com; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=mit.edu (policy=none); spf=none (imf21.hostedemail.com: domain of tytso@mit.edu has no SPF policy when checking 18.9.28.11) smtp.mailfrom=tytso@mit.edu X-Rspamd-Server: rspam03 X-HE-Tag: 1646116869-682284 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 Fri, Jan 28, 2022 at 05:47:47PM -0800, John Hubbard wrote: > By the time we meet for LSF/MM/BPF in May, the Direct IO layer will > likely be converted to use FOLL_PIN page pinning (that is, changed from > using get_user_pages_fast(), to pin_user_pages_fast()). > > Direct IO conversion to FOLL_PIN was the last missing piece, and so the > time is right to discuss how to use the output of all of this work > (which is: the ability to call page_maybe_dma_pinned()), in order to fix > one of the original problems that prompted FOLL_PIN's creation. > > That problem is: file systems do not currently tolerate having their > pages pinned and DMA'd to/from. See [1] for an extensive background of > some 11 LWN articles since 2018. > .... > > I'll volunteer to present a few slides to provide the background and get > the discussion started. It's critical to have filesystem people in > attendance for this, such as Jan Kara, Dave Chinner, Christoph Hellwig, > and many more that I won't try to list explicitly here. RDMA > representation (Jason Gunthorpe, Leon Romanovsky, Chaitanya Kulkarni, > and others) will help keep the file system folks from creating rules > that break them "too much". And of course -mm folks. There are many > people who have contributed to this project, so again, apologies for not > listing everyone explicitly. I'd definitely be interested in participating in this discussion, following up on some e-mail threads that we've had on this subject. Unfortunately a number of file system folks are listed above may not be able to attend, so I really hope we can figure out some way to allow remote participation for those people who aren't able to travel due to various reasons, including corporate policies surrounding COVID. - Ted