Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp299306imj; Sat, 16 Feb 2019 00:19:56 -0800 (PST) X-Google-Smtp-Source: AHgI3IaSYIEJcWGjdT2JUO0q/gfH5ClzBtKJaqlOiglLW5lQAGGnTeVwtQcjImUAQ4IJDKAE7nAr X-Received: by 2002:a62:39c5:: with SMTP id u66mr13719687pfj.245.1550305195907; Sat, 16 Feb 2019 00:19:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550305195; cv=none; d=google.com; s=arc-20160816; b=sAcdFmvcndyTjznIP/tMPX86RxxleSL9cB9dISthei9CFDJF1ywmA23+TVvxPiW3+k nHkHe0HXW9j9eMmbXFJsi6/wPMXZU+62d2gA8LH8rSz4alK1HK42Yu8N7Q9RRt/mUcI0 Z3OtNC7FZ7ic8l/atyXjIZ+5ESTt9T8/E5hSnqKcZ18eXYX5F5OqUnIqT8GrBvQA4j66 mePWkbI8waguz4mj1HwLkzapQxWWrM/jMladEIPkDzvSm/F708VOzlGuO5ZDtDE2h4k9 ASTngyLNCoRwyT3v+Znb2Glr8o+y4Rl9WVn76YIzMt4dJ8xdOmCJIugRhJYoWYrugiDm wjzQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=jsHka/kK1Hc1xjCHVh5Lpzl6dCeI0g7HTo9LL4LV7v8=; b=ofADxjYTzh1yOH1ipYFSDMMUEDRKXeImKSR+hzEjhnOeAf/NkI6Ji5bprpYxQx2zBW 28IMCn8MFzWID2hUSExpwWEbT9CF58X2DKejQ5GBb7M5qzjFLF1HgJU0p1yKd6rm48mh TrCKvzL8dTPyICrVTWVy56uAsujYkTpyqUnIwEr5kSZpu8iJRDPZxK51KwXgRpa2OjpL divXB8uDOIV4+VwVY97e8rMnHzpT6prdPrKGP1+9diMbXJTQja8CyKsClctpMaS2JgV7 tDNO9oka29NyRQ91OOqI3E1PkDtBcAUcQ6FJ+J1KRHT2A3WE3m55oJQ379nl141uetnY qVFA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ziepe.ca header.s=google header.b="aC851/E4"; 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 a11si5672176pls.382.2019.02.16.00.19.40; Sat, 16 Feb 2019 00:19:55 -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=@ziepe.ca header.s=google header.b="aC851/E4"; 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 S1731656AbfBOWAd (ORCPT + 99 others); Fri, 15 Feb 2019 17:00:33 -0500 Received: from mail-pl1-f193.google.com ([209.85.214.193]:34108 "EHLO mail-pl1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729239AbfBOWAd (ORCPT ); Fri, 15 Feb 2019 17:00:33 -0500 Received: by mail-pl1-f193.google.com with SMTP id w4so5594154plz.1 for ; Fri, 15 Feb 2019 14:00:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=jsHka/kK1Hc1xjCHVh5Lpzl6dCeI0g7HTo9LL4LV7v8=; b=aC851/E4mady6LQaldgvGYPai38QXy26mlgQMnBDqRtYx4sMmjhU5EAJdHh23umudw l3OCVLiijDnfppfLru7s5ESK6O1Jmtm19v4EOlfVj2MaC9u5cJk/EKoiGKGRGER5x4AN NUmhLgBvYNvr4wTZgHB/+BkA23fV6GuUXhUN/BzoWh1+uwwv81E5u/73Oqnlr92C5ELJ JGWhpsAOmFAX6W+6bhZzMuMiSk5VUydE9KKArkm83h9nKv4Rto7UdLmGyPkjwLi8Bq1F t4dM93ZaiTH3XY9Hk+Ew8j+TxpsDLeM4R4GZy4Yo9leexXMkv6gZBrLOZFeyoT8sFbd5 7zhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=jsHka/kK1Hc1xjCHVh5Lpzl6dCeI0g7HTo9LL4LV7v8=; b=l/FqVGzuDZ8J4lRyDyu0AjHbI8+Z76CYjQu7aR0ndkCfzEPsmigr3o0ku/UTYmSY1v tx+5rwGy280+lSYye04shyK16g83jHdVvNzSGOu9ZqXKPTLa8dik/BlY08AX6Nuneygp 8csYQI7+/X4ay75a35Wxs/1SrHLZtme6M5LfG4MDQu9Fl5bG9/jXNzYaiipKBdsdToQt YCGsk3bnxruJnUlLVGCUGvsB3PcPCoYsLCJ58r0JscVX/3G/SB6XKmf85lHJzXR99R15 wDEJoQ+77mb5j+EiQTIi8OmQ3F/jSGI9mrd4VRmomt+S0yNuN3hxqD4QgyABn546eb+/ TfLg== X-Gm-Message-State: AHQUAuZIKeYRHq9QfMonQbZ3FhlQVEuo9k1X2AubU3Xd5pJXeFhnOOXt 23f0o37ytEp6cfR48ZYrO+dL/Q== X-Received: by 2002:a17:902:1022:: with SMTP id b31mr12244861pla.141.1550268032901; Fri, 15 Feb 2019 14:00:32 -0800 (PST) Received: from ziepe.ca (S010614cc2056d97f.ed.shawcable.net. [174.3.196.123]) by smtp.gmail.com with ESMTPSA id g10sm7663129pgo.64.2019.02.15.14.00.32 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 15 Feb 2019 14:00:32 -0800 (PST) Received: from jgg by mlx.ziepe.ca with local (Exim 4.90_1) (envelope-from ) id 1gulX5-0001Sw-ML; Fri, 15 Feb 2019 15:00:31 -0700 Date: Fri, 15 Feb 2019 15:00:31 -0700 From: Jason Gunthorpe To: Christopher Lameter Cc: Matthew Wilcox , Dave Chinner , Jerome Glisse , Dan Williams , Jan Kara , Doug Ledford , Ira Weiny , lsf-pc@lists.linux-foundation.org, linux-rdma , Linux MM , Linux Kernel Mailing List , John Hubbard , Michal Hocko Subject: Re: [LSF/MM TOPIC] Discuss least bad options for resolving longterm-GUP usage by RDMA Message-ID: <20190215220031.GB8001@ziepe.ca> References: <20190211102402.GF19029@quack2.suse.cz> <20190211180654.GB24692@ziepe.ca> <20190214202622.GB3420@redhat.com> <20190214205049.GC12668@bombadil.infradead.org> <20190214213922.GD3420@redhat.com> <20190215011921.GS20493@dastard> <01000168f1d25e3a-2857236c-a7cc-44b8-a5f3-f51c2cfe6ce4-000000@email.amazonses.com> <20190215180852.GJ12668@bombadil.infradead.org> <01000168f26d9e0c-aef3255a-5059-4657-b241-dae66663bbea-000000@email.amazonses.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01000168f26d9e0c-aef3255a-5059-4657-b241-dae66663bbea-000000@email.amazonses.com> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 15, 2019 at 06:31:36PM +0000, Christopher Lameter wrote: > On Fri, 15 Feb 2019, Matthew Wilcox wrote: > > > > Since RDMA is something similar: Can we say that a file that is used for > > > RDMA should not use the page cache? > > > > That makes no sense. The page cache is the standard synchronisation point > > for filesystems and processes. The only problems come in for the things > > which bypass the page cache like O_DIRECT and DAX. > > It makes a lot of sense since the filesystems play COW etc games with the > pages and RDMA is very much like O_DIRECT in that the pages are modified > directly under I/O. It also bypasses the page cache in case you have > not noticed yet. It is quite different, O_DIRECT modifies the physical blocks on the storage, bypassing the memory copy. RDMA modifies the memory copy. pages are necessary to do RDMA, and those pages have to be flushed to disk.. So I'm not seeing how it can be disconnected from the page cache? Jason