Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp1559108ybt; Thu, 2 Jul 2020 08:17:43 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz6yR/ZTtzHxIfaOCoRp3BL5DxU61GYnVqBtj3qzh4fiz4zgpZk1wtWQQv8Hx3TG50ik2Ae X-Received: by 2002:a17:906:48d3:: with SMTP id d19mr27215145ejt.180.1593703062944; Thu, 02 Jul 2020 08:17:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593703062; cv=none; d=google.com; s=arc-20160816; b=W5GEje9xoxz7I6hbdc8RL97lZH/GkiUxCc5RgWF4k9kZBZ4xbVDHB5TAVy4ToeDjgg 0tfgyIWi8Pj7wAZiSOGqtTIcGWuD6HN3tohoVaBYJi6LJ2cxe6yCjZtlUnDrSSWAWxh7 LRmSTC2xqfO+ijwHONDBoX/OFEtOMP/5/EsXa4Z04TVPn3oLybnDau+YMXZ1skqGEVS2 8P+C9mka58qIeWfkCN0IWUm9Sh6JlqBm/nEXRnt7Pj/BiaqFC6MMqK9wiZyT0Tjt1+H+ 0LzMYUwkOT5nKSy7R/6irs13rVzTf994yMjK2Gtc3mQdK5D1QQ4zTLX0e/X4zEqW7WD5 GfOw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=iaHGVjmAmXhp9lutE/R+X9XTXlXuXnf2H5y3xxwJ93o=; b=GmkQqzSbbRhDlRErJJBMeeGT2h/VD+Im/m9NnsNw5GIp7H8CCS6ut6qzmtSuBmHCoG gfXtT89N3kjyAH+x9W1sXpbiRcBborL9C+S9D9I1vjq2dHtpRO5IsddjhPNO6mltOe3D zhq9SdYjAWeR7+mg8n6LqfHE58o2py7p2sp9XaDsTarMGo26u511zcyrTik68PY2fyht eGWJHQceOWC7EpArAqw+ImkroOYBv7EcAwo6gPSjj+XigkApxHocvHHnopQf39b1A2JE gPxr4z8ftZjp/RyBKBXlp6O+JSNDIoG5zzF7xzF22XAoMxT2LnyWNSlpOvpI3lcqrCW7 WFDw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=eeEdBqeD; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b23si6025204ejb.465.2020.07.02.08.17.20; Thu, 02 Jul 2020 08:17:42 -0700 (PDT) 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; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=eeEdBqeD; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729953AbgGBPQ7 (ORCPT + 99 others); Thu, 2 Jul 2020 11:16:59 -0400 Received: from us-smtp-2.mimecast.com ([205.139.110.61]:41084 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726818AbgGBPQ6 (ORCPT ); Thu, 2 Jul 2020 11:16:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1593703017; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=iaHGVjmAmXhp9lutE/R+X9XTXlXuXnf2H5y3xxwJ93o=; b=eeEdBqeDpzUZ2QharGAkPeijprs4unJMHJtTeIShJYlbJ2watqnC5ZPQcUG5odFffKTvyR HQ2ZG0v9YH9i04NT/lhDv69Vn7yfeqz5s6OW2y35A50/DMYC+0HUdhbB5z518CHELrtGvD 0QT2ZFPtyRJZScvEuPky5cYQXE3JOTI= Received: from mail-ot1-f72.google.com (mail-ot1-f72.google.com [209.85.210.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-160-jTv2jKfvMYC2hdU95xZ_7w-1; Thu, 02 Jul 2020 11:16:55 -0400 X-MC-Unique: jTv2jKfvMYC2hdU95xZ_7w-1 Received: by mail-ot1-f72.google.com with SMTP id g70so4024459otg.1 for ; Thu, 02 Jul 2020 08:16:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iaHGVjmAmXhp9lutE/R+X9XTXlXuXnf2H5y3xxwJ93o=; b=kkNUesC+XNZA72NyaBqTrUW4t9ZzXmWM2cvwHhf9kWFqcJ8mog29LT4SDkAmmzoRF+ LH+abNQ7sKWvuR7MGePaFYpzj/yBFxiOF0dpkYiagM+9mFJP3kadSFlPklD3dwUoR4rI BSz5dc4bixVeVTYXHkFJ3/XC98hgwYMLBWpgeS39H/0d3AnePiJ4HtPyeXa38qU6m2pJ 7W/hVQRx2mpZEprTyJnbW2G5Gc5D9zCGlMB96JqHqw1X3ExFJToZ3nry5dHoWKAyCbyt i1M+Ce5bakH5LY8GrXUoogRZYXHbi4P6FS6J66nyRgEAtme2PRxrjH5FjmkxfzCgIvZZ aztA== X-Gm-Message-State: AOAM530UyCj69J5Hvq4bEbSDzJv6xya19726L3GcrUNFjcfS7q3KYXne iRkiMyTHMWI0wOOrIzTCD+m8Wua/qA9Ke2qHRo8M38cpoR+U/Vs0JMGiaOWMLNmTszHNN/wv458 mNAW8pd9h55YXCgeEr1kpyw4weghm/vp1/ySMTxTi X-Received: by 2002:a05:6830:1c6e:: with SMTP id s14mr22045247otg.58.1593703014901; Thu, 02 Jul 2020 08:16:54 -0700 (PDT) X-Received: by 2002:a05:6830:1c6e:: with SMTP id s14mr22045226otg.58.1593703014619; Thu, 02 Jul 2020 08:16:54 -0700 (PDT) MIME-Version: 1.0 References: <20200619155036.GZ8681@bombadil.infradead.org> <20200622003215.GC2040@dread.disaster.area> <20200622181338.GA21350@casper.infradead.org> In-Reply-To: From: Andreas Gruenbacher Date: Thu, 2 Jul 2020 17:16:43 +0200 Message-ID: Subject: Re: [RFC] Bypass filesystems for reading cached pages To: Matthew Wilcox Cc: Dave Chinner , linux-fsdevel , Linux-MM , LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 24, 2020 at 2:35 PM Andreas Gruenbacher wrote: > On Mon, Jun 22, 2020 at 8:13 PM Matthew Wilcox wrote: > > On Mon, Jun 22, 2020 at 04:35:05PM +0200, Andreas Gruenbacher wrote: > > > I'm fine with not moving that functionality into the VFS. The problem > > > I have in gfs2 is that taking glocks is really expensive. Part of that > > > overhead is accidental, but we definitely won't be able to fix it in > > > the short term. So something like the IOCB_CACHED flag that prevents > > > generic_file_read_iter from issuing readahead I/O would save the day > > > for us. Does that idea stand a chance? > > > > For the short-term fix, is switching to a trylock in gfs2_readahead() > > acceptable? > > Well, it's the only thing we can do for now, right? It turns out that gfs2 can still deadlock with a trylock in gfs2_readahead, just differently: in this instance, gfs2_glock_nq will call inode_dio_wait. When there is pending direct I/O, we'll end up waiting for iomap_dio_complete, which will call invalidate_inode_pages2_range, which will try to lock the pages already locked for gfs2_readahead. This late in the 5.8 release cycle, I'd like to propose converting gfs2 back to use mpage_readpages. This requires reinstating mpage_readpages, but it's otherwise relatively trivial. We can then introduce an IOCB_CACHED or equivalent flag, fix the locking order in gfs2, convert gfs2 to mpage_readahead, and finally remove mage_readpages in 5.9. I'll post a patch queue that does this for comment. Thanks, Andreas