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 E5361C433F5 for ; Tue, 21 Sep 2021 21:11:14 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 79FC060F38 for ; Tue, 21 Sep 2021 21:11:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 79FC060F38 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id EF29D6B006C; Tue, 21 Sep 2021 17:11:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EA25F6B0071; Tue, 21 Sep 2021 17:11:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D69A4900002; Tue, 21 Sep 2021 17:11:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0061.hostedemail.com [216.40.44.61]) by kanga.kvack.org (Postfix) with ESMTP id C342B6B006C for ; Tue, 21 Sep 2021 17:11:13 -0400 (EDT) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 7DF8D180868F8 for ; Tue, 21 Sep 2021 21:11:13 +0000 (UTC) X-FDA: 78612826026.01.E602064 Received: from mail-qk1-f180.google.com (mail-qk1-f180.google.com [209.85.222.180]) by imf14.hostedemail.com (Postfix) with ESMTP id 466046001988 for ; Tue, 21 Sep 2021 21:11:13 +0000 (UTC) Received: by mail-qk1-f180.google.com with SMTP id f22so2117986qkm.5 for ; Tue, 21 Sep 2021 14:11:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=zCsTnszozcMWakwvCPgZXXhNyKNOkSlqncLZKwtc/cs=; b=Wo0ChhyKDc641UkRQXImePyH7Kca90qJ0M+wVAZehOGrSvyqhqySnh5pwDSXOk0Sid 099qlb+GgA+Md5pIc2x9t8aAAXPPYV8seX2/g14ugartmaCaY7UuYkfBBQU0ISzOBTeT dwKLp1d9X5/q+QaLSRww/e1Q0VptwWRZjKF4D76F4dl7Myuxa5yrPy063I0Go8wsdgjg 75FZY2e3HkRR10Ma9X5+jUyJSe1jfC4N9Jlam2kripRtLC+/ltKOmAqvRfUekbMu4wWS w+WvRBaMCqN/MVo0MNiKpmYeBv43z859ecs5sj1JGolhDF/e8XTKR5nCe9HnEVy3FFhz JWeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=zCsTnszozcMWakwvCPgZXXhNyKNOkSlqncLZKwtc/cs=; b=0NAw69+TaX1HhpnbqZM/4E/b+0fZU3NcBQIPM2lPoqi14+lRDvpeiEWD9PE4efsPl0 CD5kdTUN8PEGDaijESucvqDEjf1iMd8u2SlDS8GuCa0Z+Q9GPmpbNX8TQjFRJGsXd2cQ oB1qypmQx3gZuDIGaUkr1mlIsehxPco4F9Dl6Z5v425xoBy7HKOZBkJtQDHP/1iOoiO7 rai+r+66v+9aSrPPGfntt4SWYCZ8uWsUrAbLnf2TS+t2+MEpqLzBETegA1YSflUp/+Mz QlDqvOWrfr/XsxIME/SuIDYRjpqSQjj/4V2mqXFPWL+8Lp602O/0QKjcShhydLLU1klJ FZtA== X-Gm-Message-State: AOAM530YLVdsc5LmoXWT5rUDytAaUjm7cFHYtXklyZj5t4lX12lSvPAH fzqmw3b3d5zXF7NHuAkFFA== X-Google-Smtp-Source: ABdhPJwawa4dME/5/GH0r/McBHz9A74FW3KWI/lcJzN9mewwiCovRyE/eKFXpxKF9RWNgIO1YdwFzA== X-Received: by 2002:ae9:efc9:: with SMTP id d192mr15818686qkg.366.1632258672543; Tue, 21 Sep 2021 14:11:12 -0700 (PDT) Received: from moria.home.lan (c-73-219-103-14.hsd1.vt.comcast.net. [73.219.103.14]) by smtp.gmail.com with ESMTPSA id m21sm131906qka.69.2021.09.21.14.11.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Sep 2021 14:11:11 -0700 (PDT) Date: Tue, 21 Sep 2021 17:11:09 -0400 From: Kent Overstreet To: Matthew Wilcox Cc: Johannes Weiner , Linus Torvalds , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Andrew Morton , "Darrick J. Wong" , Christoph Hellwig , David Howells Subject: Re: Folio discussion recap Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: u75kt9hkoc1pjrrc575y3iq86qi85gm9 Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Wo0ChhyK; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf14.hostedemail.com: domain of kent.overstreet@gmail.com designates 209.85.222.180 as permitted sender) smtp.mailfrom=kent.overstreet@gmail.com X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 466046001988 X-HE-Tag: 1632258673-20105 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, Sep 21, 2021 at 09:38:54PM +0100, Matthew Wilcox wrote: > On Tue, Sep 21, 2021 at 03:47:29PM -0400, Johannes Weiner wrote: > > and so the justification for replacing page with folio *below* those > > entry points to address tailpage confusion becomes nil: there is no > > confusion. Move the anon bits to anon_page and leave the shared bits > > in page. That's 912 lines of swap_state.c we could mostly leave alone. > > Your argument seems to be based on "minimising churn". Which is certainly > a goal that one could have, but I think in this case is actually harmful. > There are hundreds, maybe thousands, of functions throughout the kernel > (certainly throughout filesystems) which assume that a struct page is > PAGE_SIZE bytes. Yes, every single one of them is buggy to assume that, > but tracking them all down is a never-ending task as new ones will be > added as fast as they can be removed. Yet it's only file backed pages that are actually changing in behaviour right now - folios don't _have_ to be the tool to fix that elsewhere, for anon, for network pools, for slab. > > The anon_page->page relationship may look familiar too. It's a natural > > type hierarchy between superclass and subclasses that is common in > > object oriented languages: page has attributes and methods that are > > generic and shared; anon_page and file_page encode where their > > implementation differs. > > > > A type system like that would set us up for a lot of clarification and > > generalization of the MM code. For example it would immediately > > highlight when "generic" code is trying to access type-specific stuff > > that maybe it shouldn't, and thus help/force us refactor - something > > that a shared, flat folio type would not. > > If you want to try your hand at splitting out anon_folio from folio > later, be my guest. I've just finished splitting out 'slab' from page, > and I'll post it later. I don't think that splitting anon_folio from > folio is worth doing, but will not stand in your way. I do think that > splitting tail pages from non-tail pages is worthwhile, and that's what > this patchset does. Eesh, we can and should hold ourselves to a higher standard in our technical discussions. Let's not let past misfourtune (and yes, folios missing 5.15 _was_ unfortunate and shouldn't have happened) colour our perceptions and keep us from having productive working relationships going forward. The points Johannes is bringing up are valid and pertinent and deserve to be discussed. If you're still trying to sell folios as the be all, end all solution for anything using compound pages, I think you should be willing to make the argument that that really is the _right_ solution - not just that it was the one easiest for you to implement. Actual code might make this discussion more concrete and clearer. Could you post your slab conversion?