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=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 CC0B4C433E0 for ; Mon, 22 Jun 2020 14:35:24 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 75FE22071A for ; Mon, 22 Jun 2020 14:35:24 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="KylTvNx5" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 75FE22071A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id B7A456B0002; Mon, 22 Jun 2020 10:35:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B2C256B0003; Mon, 22 Jun 2020 10:35:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A1AF96B0008; Mon, 22 Jun 2020 10:35:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0117.hostedemail.com [216.40.44.117]) by kanga.kvack.org (Postfix) with ESMTP id 81E746B0002 for ; Mon, 22 Jun 2020 10:35:23 -0400 (EDT) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id CA581180AC581 for ; Mon, 22 Jun 2020 14:35:22 +0000 (UTC) X-FDA: 76957095684.26.war04_0e17a9026e33 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin26.hostedemail.com (Postfix) with ESMTP id A473A18237307 for ; Mon, 22 Jun 2020 14:35:22 +0000 (UTC) X-HE-Tag: war04_0e17a9026e33 X-Filterd-Recvd-Size: 4496 Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by imf17.hostedemail.com (Postfix) with ESMTP for ; Mon, 22 Jun 2020 14:35:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1592836521; 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=m8LciREWJsj9AQY8WoqbJEs9+BzHuuZ2kYt75+dmYbI=; b=KylTvNx5p+XzGCl2XL4lqyj9IgnIfF2a9gf6gX4+BiCKKglca/2+DBvPIg+Kh1gd9Ijpbr Q5mJHiz09oCZvnKGgvQ/OR5gELvtoPdYK/Ri/W8jWNwWGKqixA8dwFHGwHcGdFL6AwCTp1 1gu7Pf/trqiGOJ8saL+1vONisLHTY6o= Received: from mail-oi1-f198.google.com (mail-oi1-f198.google.com [209.85.167.198]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-250-fDgJfuVJMOSvHkmaZjEtDQ-1; Mon, 22 Jun 2020 10:35:18 -0400 X-MC-Unique: fDgJfuVJMOSvHkmaZjEtDQ-1 Received: by mail-oi1-f198.google.com with SMTP id a18so8136019oib.2 for ; Mon, 22 Jun 2020 07:35:17 -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=m8LciREWJsj9AQY8WoqbJEs9+BzHuuZ2kYt75+dmYbI=; b=F2QkVcuB8Z+qsnqKmFNIET2GNT/wPrBoHf8mD30qzB6EnFg9a2reImtjVk6ilFRBUP e0aKprXIPUJk32oxsf/IDrraWKeof44FA5PZufVHY53uXGlBLOb1TjVOh4HM9dc6qtkf nY2BWvCb7MoRyQHrR+rlqHq+g1KKmWXAEBcrVjN9ZFF0xFAu4P9XCEH2d9KLEl+jc1GX 4Va8iROoILgTzvomflmTsxnL49JJgJJI6J6jOIntVQstA5X5cljqOuSZvHwvcUdeeRq+ NrFfdVzmv30zTXjuyVya8NwUbqQmAEOxj8u86Rt0pTOddnfaZSOIDR5osGWtyt04kBex VRWg== X-Gm-Message-State: AOAM530LiYn34fPzs17bmV8dcss1kq5t3LUk0FsqAAJ07FjCbVRwbiIB 138WxbNIxlA00uvKgTvSweElplWXAwpn4G42h+yUFK1NGvV5qjVOI2I4W9GP/tqPB+ypJFdgZ7T mv50P00EAdsfJX4uqy8xtQHnjtR8= X-Received: by 2002:a4a:868a:: with SMTP id x10mr5394725ooh.31.1592836517161; Mon, 22 Jun 2020 07:35:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzmNbgEQyfxangZ/xtw/LtBecn8SD7Han8BUwPHyelwFuDLXZvgVZ4AhpiZLmG4l0zJHroGpJ6M/R2ujIRrCNs= X-Received: by 2002:a4a:868a:: with SMTP id x10mr5394700ooh.31.1592836516902; Mon, 22 Jun 2020 07:35:16 -0700 (PDT) MIME-Version: 1.0 References: <20200619155036.GZ8681@bombadil.infradead.org> <20200622003215.GC2040@dread.disaster.area> In-Reply-To: <20200622003215.GC2040@dread.disaster.area> From: Andreas Gruenbacher Date: Mon, 22 Jun 2020 16:35:05 +0200 Message-ID: Subject: Re: [RFC] Bypass filesystems for reading cached pages To: Dave Chinner Cc: Matthew Wilcox , linux-fsdevel , Linux-MM , LKML X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: A473A18237307 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 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 Mon, Jun 22, 2020 at 2:32 AM Dave Chinner wrote: > On Fri, Jun 19, 2020 at 08:50:36AM -0700, Matthew Wilcox wrote: > > > > This patch lifts the IOCB_CACHED idea expressed by Andreas to the VFS. > > The advantage of this patch is that we can avoid taking any filesystem > > lock, as long as the pages being accessed are in the cache (and we don't > > need to readahead any pages into the cache). We also avoid an indirect > > function call in these cases. > > What does this micro-optimisation actually gain us except for more > complexity in the IO path? > > i.e. if a filesystem lock has such massive overhead that it slows > down the cached readahead path in production workloads, then that's > something the filesystem needs to address, not unconditionally > bypass the filesystem before the IO gets anywhere near it. 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? We could theoretically also create a copy of generic_file_buffered_read in gfs2 and strip out the I/O parts, but that would be very messy. Thanks, Andreas