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=-2.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 3A4B4C433B4 for ; Fri, 2 Apr 2021 06:19:50 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id ABF38610E8 for ; Fri, 2 Apr 2021 06:19:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org ABF38610E8 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id BB83F6B0071; Fri, 2 Apr 2021 02:19:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B674D6B0072; Fri, 2 Apr 2021 02:19:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A09656B0073; Fri, 2 Apr 2021 02:19:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0043.hostedemail.com [216.40.44.43]) by kanga.kvack.org (Postfix) with ESMTP id 8241D6B0071 for ; Fri, 2 Apr 2021 02:19:48 -0400 (EDT) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 2870918089AB2 for ; Fri, 2 Apr 2021 06:19:48 +0000 (UTC) X-FDA: 77986426056.04.5F10A94 Received: from mail-il1-f174.google.com (mail-il1-f174.google.com [209.85.166.174]) by imf09.hostedemail.com (Postfix) with ESMTP id E9F3F6000109 for ; Fri, 2 Apr 2021 06:19:46 +0000 (UTC) Received: by mail-il1-f174.google.com with SMTP id r17so4048329ilt.0 for ; Thu, 01 Apr 2021 23:19:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=44Sen/sBOu6E6dI3+swHBDOOeHMhhOSYmQFra7wWgWM=; b=A4p8Q5kjRHDn7T1INRDlx1CA46ppc5lqZ9Y5tR22QbUQE4JmcSLSlTgRavElqkFlPN q2VqXolnBSooi3TAnCKxfmdmoeu+IDoWIDyk1qKyvMoAcqTT3maX/YrDW7W/IS3yJvwp QkxUoA01apspYrU/jnabqO1W5aDfr+S4jaUwDhfbT5JwrYD9M1pF2bHwKyezTzloLyxO OFrqpJ2ugJ6hUC5Nqv7TjX2lcd4mMQD3rnlX8FoA3NtAHoI7JdEIWG6WELjODpSiwsg+ QlocUunyDDwSHHrVpgI4zBj621hipJDLxF4+pUAvmXTG4mVm99szOgnj4Yf64ENg2Oej Cihg== 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=44Sen/sBOu6E6dI3+swHBDOOeHMhhOSYmQFra7wWgWM=; b=HuIByOmlDheSqQuGxIQRkydCHFfqpoCKr9lRzwwOgm1JJOdyFxLqdI/qNEpek1Y+PM wvzLIT147S2cQF2DbY5yMAmmCF2sSChyv+cXShSarEGTe+n6D2kXu491+pNZTjI6oHaq CvP65zYyp2IYIigD58CFC84vHH6P5tx4myCj7und4jDWWX2WLLCqUmKQA9sqy+VEeig0 I0aAAD/4XSjHiSRwllqkP4mh4HTcygeBM9lCSAjTg9EnDtGwU9NbKVPkiLsv0GkPJWUg flggCaQ8joGx9CjE69JqyDapDuqrMoMpzTYS/znVcfV6chMcf9fOKXr8QOGaSCqFLHE5 NOuQ== X-Gm-Message-State: AOAM531qhvSuRTHn21uuggJfNRYh7gzseiRl9+kqjwyPOnpkNyVT+lUb PMzmzQWrMv38HiglT6qrxOFtakOxihY9eOYkFxVRi1C3vwQ= X-Google-Smtp-Source: ABdhPJyzJEDKTydXW/A8QNmnZ8I6gAv437PMJVIRUEJjpmVTLK9+HqMwT5rc+FLlIgZfP19axW8IHW9mwXXEe+KHAAk= X-Received: by 2002:a92:2c08:: with SMTP id t8mr9814763ile.72.1617344387083; Thu, 01 Apr 2021 23:19:47 -0700 (PDT) MIME-Version: 1.0 References: <20210325032202.GS1719932@casper.infradead.org> In-Reply-To: <20210325032202.GS1719932@casper.infradead.org> From: Amir Goldstein Date: Fri, 2 Apr 2021 09:19:36 +0300 Message-ID: Subject: Re: [RFC] Convert sysv filesystem to use folios exclusively To: Matthew Wilcox Cc: Linux MM , linux-fsdevel , linux-kernel , Christoph Hellwig Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: E9F3F6000109 X-Stat-Signature: hjzr9d3th4fpkrj8dfeorwe8msdmuioa Received-SPF: none (gmail.com>: No applicable sender policy available) receiver=imf09; identity=mailfrom; envelope-from=""; helo=mail-il1-f174.google.com; client-ip=209.85.166.174 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1617344386-663162 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 Thu, Mar 25, 2021 at 5:43 AM Matthew Wilcox wrote: > > > I decided to see what a filesystem free from struct page would look > like. I chose sysv more-or-less at random; I wanted a relatively simple > filesystem, but I didn't want a toy. The advantage of sysv is that the > maintainer is quite interested in folios ;-) > > $ git grep page fs/sysv > fs/sysv/dir.c:#include > fs/sysv/dir.c: if (offset_in_page(diter->pos)) { > fs/sysv/inode.c: .get_link = page_get_link, > fs/sysv/inode.c: truncate_inode_pages_final(&inode->i_data); > fs/sysv/itree.c: block_truncate_page(inode->i_mapping, inode->i_size, get_block); > fs/sysv/itree.c: truncate_pagecache(inode, inode->i_size); > fs/sysv/itree.c: .readpage = sysv_read_folio, > fs/sysv/itree.c: .writepage = sysv_write_folio, I would like to address only the social engineering aspect of the s/page/folio conversion. Personally, as a filesystem developer, I find the concept of the folio abstraction very useful and I think that the word is short, clear and witty. But the example above (writepage = sysv_write_folio) just goes to show how deeply rooted the term 'page' is throughout the kernel and this is just the tip of the iceberg. There are documents, comments and decades of using 'page' in our language - those will be very hard to root out. My first impression from looking at sample patches is that 90% of the churn does not serve any good purpose and by that, I am referring to the conversion of local variable names and struct field names s/page/folio. Those conversions won't add any clarity to subsystems that only need to deal with the simple page type (i.e. non-tail pages). The compiler type checks will have already did that job already and changing the name of the variables does not help in this case. I think someone already proposed the "boring" name struct page_head as a replacement for the "cool" name struct folio. Whether it's page_head, page_ref or what not, anything that can be written in a way that these sort of "thin" conversions make sense: -static int sysv_readpage(struct file *file, struct page *page) +static int sysv_readpage(struct file *file, struct page_head *page) { return block_read_full_page(page, get_block); } So when a filesystem developer reviews your conversion patch he goes: "Whatever, if the compiler says this is fine, it's fine". Thanks, Amir.