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=-3.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 154F3C433DB for ; Tue, 16 Feb 2021 13:24:25 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C50B764DDA for ; Tue, 16 Feb 2021 13:24:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C50B764DDA Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 2E5708D0179; Tue, 16 Feb 2021 08:24:23 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 295438D0176; Tue, 16 Feb 2021 08:24:23 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1875C8D0179; Tue, 16 Feb 2021 08:24:23 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0220.hostedemail.com [216.40.44.220]) by kanga.kvack.org (Postfix) with ESMTP id 023918D0176 for ; Tue, 16 Feb 2021 08:24:22 -0500 (EST) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id BAFFB8E63 for ; Tue, 16 Feb 2021 13:24:22 +0000 (UTC) X-FDA: 77824199964.16.9C05F24 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf24.hostedemail.com (Postfix) with ESMTP id 61AE8A0009DA for ; Tue, 16 Feb 2021 13:24:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=hgIp8cMPVwAuFQ5Q63EIotyWvfFSj1q5sKGA4WuuKGw=; b=ctbhiVSDQqbf2BoXqncvKXwa5V yyZuAi6Jd2FD+1ogrQXZd4B3GkugraUEBxghjXti1sjtmIMBZbtRojFeQVOLvcSCNN7KWI8zGjHRB aTbPwSH/89Xk8nb6cxXt7r/DpupCtu6PRowMHNCggqKOsYqrSAKydaABwFJxd50yJQZnTj8UdGVoW V0fYtHecjoaTww/OoSZkKEThNGDBmEEDfNhjuoQuWlthj7jZ2lk6XmekUKGID08dGYnEgvpmu1c/k v7MMetTzabs77GeK+SjHzRTKERB2iiyjh2pOZt5/wPCbJ4YKul+uZv2isOLBi843nry0+UN0Q914n 9/DbbT1w==; Received: from willy by casper.infradead.org with local (Exim 4.94 #2 (Red Hat Linux)) id 1lC0JX-00Gtih-RC; Tue, 16 Feb 2021 13:22:58 +0000 Date: Tue, 16 Feb 2021 13:22:51 +0000 From: Matthew Wilcox To: Christoph Hellwig Cc: David Howells , Trond Myklebust , Anna Schumaker , Steve French , Dominique Martinet , Alexander Viro , linux-mm@kvack.org, linux-cachefs@redhat.com, linux-afs@lists.infradead.org, linux-nfs@vger.kernel.org, linux-cifs@vger.kernel.org, ceph-devel@vger.kernel.org, v9fs-developer@lists.sourceforge.net, linux-fsdevel@vger.kernel.org, Jeff Layton , David Wysochanski , linux-kernel@vger.kernel.org Subject: Re: [PATCH 03/33] mm: Implement readahead_control pageset expansion Message-ID: <20210216132251.GI2858050@casper.infradead.org> References: <161340385320.1303470.2392622971006879777.stgit@warthog.procyon.org.uk> <161340389201.1303470.14353807284546854878.stgit@warthog.procyon.org.uk> <20210216103215.GB27714@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210216103215.GB27714@lst.de> X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 61AE8A0009DA X-Stat-Signature: yiafoym4m5ofarua1e8qkdmzejqoauef Received-SPF: none (infradead.org>: No applicable sender policy available) receiver=imf24; identity=mailfrom; envelope-from=""; helo=casper.infradead.org; client-ip=90.155.50.34 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1613481857-7253 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 Tue, Feb 16, 2021 at 11:32:15AM +0100, Christoph Hellwig wrote: > On Mon, Feb 15, 2021 at 03:44:52PM +0000, David Howells wrote: > > Provide a function, readahead_expand(), that expands the set of pages > > specified by a readahead_control object to encompass a revised area with a > > proposed size and length. > > > > The proposed area must include all of the old area and may be expanded yet > > more by this function so that the edges align on (transparent huge) page > > boundaries as allocated. > > > > The expansion will be cut short if a page already exists in either of the > > areas being expanded into. Note that any expansion made in such a case is > > not rolled back. > > > > This will be used by fscache so that reads can be expanded to cache granule > > boundaries, thereby allowing whole granules to be stored in the cache, but > > there are other potential users also. > > So looking at linux-next this seems to have a user, but that user is > dead wood given that nothing implements ->expand_readahead. > > Looking at the code structure I think netfs_readahead and > netfs_rreq_expand is a complete mess and needs to be turned upside > down, that is instead of calling back from netfs_readahead to the > calling file system, split it into a few helpers called by the > caller. That's funny, we modelled it after iomap. > But even after this can't we just expose the cache granule boundary > to the VM so that the read-ahead request gets setup correctly from > the very beginning? The intent is that this be usable by filesystems which want to (for example) compress variable sized blocks. So they won't know which pages they want to readahead until they're in their iomap actor routine, see that the extent they're in is compressed, and find out how large the extent is.