Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp691463imj; Thu, 7 Feb 2019 10:18:14 -0800 (PST) X-Google-Smtp-Source: AHgI3IaL7MaVrktyahzh1W6IsRpDLwFlWeKE9FpMk72BBnmGYagfMTVZnwKyP+wodZrwxjvmjGuY X-Received: by 2002:a17:902:8687:: with SMTP id g7mr17756838plo.96.1549563494836; Thu, 07 Feb 2019 10:18:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1549563494; cv=none; d=google.com; s=arc-20160816; b=OF6QlmLFYqNi4RZ2xV3DXLEuWiF6Zz4AECva2CGJqqSxzVBvOnnNJTMSqiGilD1lyG L6ixP5tgfh0KsxcGsnbVjzlDDEFZ8BHXxV7UYl7bNObynb/qGR7Xdm7ap5lJnJNzz01e 87/C6HvTm7MJUG9Lo9+uQ2PoUcqv1Okb56tkHvWlT1DnUXb1uV9u2MwLrbQEwCoJ8S2y yui3bmHuB2Z+uCYkR5Lx7egKJ0n9ucz2YxlYdP++vH3wFsxEEYk2upRlSVC1C3QT7eh0 AyoWtbHDfXNt1PVz5uYlqKSZkDRpvliAdEuDn0N7z8UCPt9wEgbrUNd2w+uTawEa7Bw+ SZBQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:feedback-id:mime-version:user-agent :references:message-id:in-reply-to:subject:cc:to:from:date :dkim-signature; bh=DxakVmrk+rxFQSFA39vWF6fSPdcTuwBUfQ7c7/5uFy0=; b=ThE19UTj6Mh0DSQchFMJkpYyyiPv/jYabcFb5BpEBAxDoBTb3RqJdQjqP0rGoZWjAm YStn4jV0XBy3ZBgYyjtpRi6UiKNgKdSrgPLIp8+4lsMMIQqP2dMx4Sti4UTxF1q5/QKb qqWtY33fCLfgJdf1didgV4DhNr7UWv7FOwvK94P6sRc+nhXhDF6g/P/KCOfRuPtJt8cS WVb9T8uNyqK6Gjqv7R1+yoljKOkYnzGswZXOSsEFOSwE89MI+PELesa02DKHIHNT6OMX +9xJ3I/Grg3b+AyMVTocbhXszHfW+Mi88qS4tAI+Snop+flnPWtN9SeXQH7CCqdUk6Al WQ3g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amazonses.com header.s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug header.b="B47/aMZw"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o89si10100470pfk.223.2019.02.07.10.17.58; Thu, 07 Feb 2019 10:18:14 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@amazonses.com header.s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug header.b="B47/aMZw"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726924AbfBGSRs (ORCPT + 99 others); Thu, 7 Feb 2019 13:17:48 -0500 Received: from a9-36.smtp-out.amazonses.com ([54.240.9.36]:38788 "EHLO a9-36.smtp-out.amazonses.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726319AbfBGSRr (ORCPT ); Thu, 7 Feb 2019 13:17:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1549563466; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:MIME-Version:Content-Type:Feedback-ID; bh=0VffAsrUHZUiZ63MsIfnIIlVBW7/RgvsuDezdKupRM8=; b=B47/aMZwpGCuvge66yAeFJ1YIM+i7xuALx1AU+6y+BctQkRsA7s32uTkotT6ixxR vRbR+yOqW3PfCcHyIw/t1tgS5858WaLW0Xvd8Cy13zvdjhKQdEvTXRV4aC+QXAUOURh MjDzJiPT3clgimtKm27lFmPphToHGq2F8d0JBoLA= Date: Thu, 7 Feb 2019 18:17:46 +0000 From: Christopher Lameter X-X-Sender: cl@nuc-kabylake To: Ira Weiny cc: Doug Ledford , Dan Williams , Jason Gunthorpe , Dave Chinner , Matthew Wilcox , Jan Kara , lsf-pc@lists.linux-foundation.org, linux-rdma , Linux MM , Linux Kernel Mailing List , John Hubbard , Jerome Glisse , Michal Hocko Subject: Re: [LSF/MM TOPIC] Discuss least bad options for resolving longterm-GUP usage by RDMA In-Reply-To: <20190207173504.GD29531@iweiny-DESK2.sc.intel.com> Message-ID: <01000168c92e1220-36386b5d-66f7-4ba5-ba0e-d314b1d26cf8-000000@email.amazonses.com> References: <20190206173114.GB12227@ziepe.ca> <20190206175233.GN21860@bombadil.infradead.org> <47820c4d696aee41225854071ec73373a273fd4a.camel@redhat.com> <01000168c43d594c-7979fcf8-b9c1-4bda-b29a-500efe001d66-000000@email.amazonses.com> <20190206210356.GZ6173@dastard> <20190206220828.GJ12227@ziepe.ca> <0c868bc615a60c44d618fb0183fcbe0c418c7c83.camel@redhat.com> <01000168c8e2de6b-9ab820ed-38ad-469c-b210-60fcff8ea81c-000000@email.amazonses.com> <20190207173504.GD29531@iweiny-DESK2.sc.intel.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-SES-Outgoing: 2019.02.07-54.240.9.36 Feedback-ID: 1.us-east-1.fQZZZ0Xtj2+TD7V5apTT/NrT6QKuPgzCT/IC7XYgDKI=:AmazonSES Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 7 Feb 2019, Ira Weiny wrote: > On Thu, Feb 07, 2019 at 04:55:37PM +0000, Christopher Lameter wrote: > > One approach that may be a clean way to solve this: > > > > 1. Long term GUP usage requires the virtual mapping to the pages be fixed > > for the duration of the GUP Map. There never has been a way to break > > the pinnning and thus this needs to be preserved. > > How does this fit in with the changes John is making? > > > > > 2. Page Cache Long term pins are not allowed since regular filesystems > > depend on COW and other tricks which are incompatible with a long term > > pin. > > Unless the hardware supports ODP or equivalent functionality. Right? Ok we could make an exception there. But that is not required as a first step and only some hardware would support it. > > 3. Filesystems that allow bypass of the page cache (like XFS / DAX) will > > provide the virtual mapping when the PIN is done and DO NO OPERATIONS > > on the longterm pinned range until the long term pin is removed. > > Hardware may do its job (like for persistent memory) but no data > > consistency on the NVDIMM medium is guaranteed until the long term pin > > is removed and the filesystems regains control over the area. > > I believe Dan attempted something like this and it became pretty difficult. What is difficult about leaving things alone that are pinned? We already have to do that currently because the refcount is elevated.