Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp1615377pxb; Mon, 20 Sep 2021 00:37:06 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwFsuDhAysmnZNaCUkUzg/8DPfxGUMetPPTO4j+9E1IGH/3+CE13zLttZSvIvqKM0P9qnqP X-Received: by 2002:a5d:9708:: with SMTP id h8mr17360672iol.170.1632123426692; Mon, 20 Sep 2021 00:37:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632123426; cv=none; d=google.com; s=arc-20160816; b=bgMhrvgFsAKuho7GohScj6igIGOcCDkYREOzEOdY4WYFxTLbbaPPKaeeQhK+HBpXer eTmzeUvgqyl/h4KX/yk5rllGP2KSvteqsKClDYxhEXVn6ygF0+NspBc1hoHfLkKz4vFD c6S0uEW8itx3jy4v+EKfv1AJssn545DvA6sx48FR9gYaMGmmJgMRp0PA8YZS7AIvj/Sr Vdhdz5st/nKJ3KKSUO/hHiDYzyRkyR2FReJaFvdM7Pqj0PL/U9J51VUHkc89MvOWn5DH EUYfgYKAMJu0gxXskUahntiCE8vzqYmUTwmc58Ai6NgeYZsE3zyQtSIP5CpcxOQuMkxV btAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=ObjLS5rWwA+pgraZw+v9QGs514X1Tl1NI7rZo227KCQ=; b=E/0Wz7FN//UGVPSzS8oVOZrtiYxCvN3Xv4mPyIed37jBY7ZVHsojqWqA4C+x/wui5t 00b57bUm5ffA9g4HipUojrG3enEFR5jl8x3+Jb7zSgoC0o6/Jo0ZaKzXOyEatlkoLCfu OPNtgiRi39D4MPQqBIyju2swU7uMOdNzIy3DokqFHLNnDkgsYqxQNraS8wAn1dRlhyPd c+aLp0sMLoBZneIyDXXeAtlLGxtvn8mSXvQQK9MhexN/WUmWlT0gE0JkyEQ39YgFbEYg CgufHSOmB9+OoQ8b3PsGcI6Me/gqDuzq+gx+8AxiQQe7T00xwm/c/3ZJnIRSx44opYsh 1yBQ== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d10si4594136ilu.50.2021.09.20.00.36.55; Mon, 20 Sep 2021 00:37:06 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230519AbhITBGS (ORCPT + 99 others); Sun, 19 Sep 2021 21:06:18 -0400 Received: from mail107.syd.optusnet.com.au ([211.29.132.53]:33268 "EHLO mail107.syd.optusnet.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229755AbhITBGS (ORCPT ); Sun, 19 Sep 2021 21:06:18 -0400 Received: from dread.disaster.area (pa49-195-238-16.pa.nsw.optusnet.com.au [49.195.238.16]) by mail107.syd.optusnet.com.au (Postfix) with ESMTPS id AE8CB98D5; Mon, 20 Sep 2021 11:04:48 +1000 (AEST) Received: from dave by dread.disaster.area with local (Exim 4.92.3) (envelope-from ) id 1mS7jj-00ETf4-GT; Mon, 20 Sep 2021 11:04:47 +1000 Date: Mon, 20 Sep 2021 11:04:47 +1000 From: Dave Chinner To: Kent Overstreet Cc: Johannes Weiner , "Darrick J. Wong" , Matthew Wilcox , Linus Torvalds , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Andrew Morton , Christoph Hellwig , David Howells Subject: Re: Folio discussion recap Message-ID: <20210920010447.GU2361455@dread.disaster.area> References: <20210916025854.GE34899@magnolia> <20210917052440.GJ1756565@dread.disaster.area> <20210918010440.GK1756565@dread.disaster.area> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.3 cv=Tu+Yewfh c=1 sm=1 tr=0 a=DzKKRZjfViQTE5W6EVc0VA==:117 a=DzKKRZjfViQTE5W6EVc0VA==:17 a=kj9zAlcOel0A:10 a=7QKq2e-ADPsA:10 a=7-415B0cAAAA:8 a=St-ALpV-QOArFpp15CwA:9 a=CjuIK1q_8ugA:10 a=biEYGPWJfzWAr4FL6Ov7:22 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Sep 18, 2021 at 12:51:50AM -0400, Kent Overstreet wrote: > On Sat, Sep 18, 2021 at 11:04:40AM +1000, Dave Chinner wrote: > > As for long term, everything in the page cache API needs to > > transition to byte offsets and byte counts instead of units of > > PAGE_SIZE and page->index. That's a more complex transition, but > > AFAIA that's part of the future work Willy is intended to do with > > folios and the folio API. Once we get away from accounting and > > tracking everything as units of struct page, all the public facing > > APIs that use those units can go away. > > Probably 95% of the places we use page->index and page->mapping aren't necessary > because we've already got that information from the context we're in and > removing them would be a useful cleanup *nod* > - if we've already got that from context > (e.g. we're looking up the page in the page cache, via i_pageS) eliminating the > page->index or page->mapping use means we're getting rid of a data dependency so > it's good for performance - but more importantly, those (much fewer) places in > the code where we actually _do_ need page->index and page->mapping are really > important places to be able to find because they're interesting boundaries > between different components in the VM. *nod* This is where infrastructure like like write_cache_pages() is problematic. It's not actually a component of the VM - it's core page cache/filesystem API functionality - but the implementation is determined by the fact there is no clear abstraction between the page cache and the VM and so while the filesysetm side of the API is byte-ranged based, the VM side is struct page based and so the impedence mismatch has to be handled in the page cache implementation. Folios are definitely pointing out issues like this whilst, IMO, demonstrating that an abstraction like folios are also a necessary first step to address the problems they make obvious... Cheers, Dave. -- Dave Chinner david@fromorbit.com