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 ADEE3C433FE for ; Fri, 17 Sep 2021 21:13:15 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 287AF61164 for ; Fri, 17 Sep 2021 21:13:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 287AF61164 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 7E57B6B0071; Fri, 17 Sep 2021 17:13:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 76E1C900003; Fri, 17 Sep 2021 17:13:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5E8AE900002; Fri, 17 Sep 2021 17:13:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0069.hostedemail.com [216.40.44.69]) by kanga.kvack.org (Postfix) with ESMTP id 4D7C96B0071 for ; Fri, 17 Sep 2021 17:13:14 -0400 (EDT) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 084608248076 for ; Fri, 17 Sep 2021 21:13:14 +0000 (UTC) X-FDA: 78598315908.10.C76FF73 Received: from mail-qt1-f173.google.com (mail-qt1-f173.google.com [209.85.160.173]) by imf21.hostedemail.com (Postfix) with ESMTP id C3C90D0302F4 for ; Fri, 17 Sep 2021 21:13:13 +0000 (UTC) Received: by mail-qt1-f173.google.com with SMTP id 2so9995861qtw.1 for ; Fri, 17 Sep 2021 14:13: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=7y2hlBvrXziI3IvJBrIxyx+hcslOAnsyk0h3WElgiQM=; b=YhUzpzg0wYgXhTIQgYtpVQo+Di+Z9+TAbAQY1M2JcfS7RmVqDtKpqT0AChc3ODGbcb GRvUx8gveyi9adfSYVUeXWxkaIXhCpXRt6+l2NWCabX3r2j+LqMx+6d8fDDEXI72fy9j w3I/J7K+x6lns6moYBks/jiCqKmEjvWtQbvpSmVTlV3gl5iGS3IPT3MZyNI5G04SvG5u rlNIuYdHIoAaO6aC0HbpjK0hPOcjW1jX8hhWeA8I8Z0wQ5bUe2yfNCOhZyGbzV5f5EyV YFQ8vGl94WSsxA1Ah/smYcGKbTFLQlTHEkyp/3fLCrVH8CKHKEddBflPF8JhzKsNy/bl CWxQ== 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=7y2hlBvrXziI3IvJBrIxyx+hcslOAnsyk0h3WElgiQM=; b=1/XdMxX1vKFoi5Xsfr3t9CbMO9WeM1ufHrSd6jS4mCtvpzBh8Bh3lja+1qV0cqqpWF XXJg9tLCEpmlLERrlKt0log2ySkpYXWsgMLXY8cXik38RqXOlnbR2giCESQS0MBFic73 zkmJQW789JceWLjcvYojNh5z/2ZZkh+U7XqmUYWH6yE+IB2tzhwSsXEM3RJNwue0/R5B vHPG20ZT5ISI+HyMHYweCPhqVMfipssFh720d+TA/RjnruV7P1oyro2VLrSae+88a48a sLPqfCM6uwIiErTtsF5RluCzuaHLq38+Rob6v4GDio4vMgKIMPNig1Rsci4YB5ozSOLB AkBQ== X-Gm-Message-State: AOAM533SJKMGkiAPI/aGvT1Jbs0hwkiOsPGzucmChrW2JDG18QQyTKn5 KK13G16EScxsPTbJn7y0WA== X-Google-Smtp-Source: ABdhPJycdfl7F3ccjTutXpAnulSbeVr4KJYDT9+KCiiUwwpDuj35k/zIHcKcPugbVWRZukA41a7uSQ== X-Received: by 2002:ac8:570f:: with SMTP id 15mr12568002qtw.335.1631913192909; Fri, 17 Sep 2021 14:13: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 o4sm4933735qti.24.2021.09.17.14.13.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Sep 2021 14:13:12 -0700 (PDT) Date: Fri, 17 Sep 2021 17:13:10 -0400 From: Kent Overstreet To: Johannes Weiner Cc: Dave Chinner , "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: References: <20210916025854.GE34899@magnolia> <20210917052440.GJ1756565@dread.disaster.area> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: C3C90D0302F4 Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=YhUzpzg0; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf21.hostedemail.com: domain of kent.overstreet@gmail.com designates 209.85.160.173 as permitted sender) smtp.mailfrom=kent.overstreet@gmail.com X-Stat-Signature: o3pdzz43ksyt95dhcgrnzq5j5uuukurk X-HE-Tag: 1631913193-666915 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: Snipped, reordered: On Fri, Sep 17, 2021 at 12:31:36PM -0400, Johannes Weiner wrote: > 2. Are compound pages a scalable, future-proof allocation strategy? > > For 2), nobody knows the answer to this. Nobody. Anybody who claims to > do so is full of sh*t. Maybe compound pages work out, maybe they > don't. We can talk a million years about larger page sizes, how to > handle internal fragmentation, the difficulties of implementing a > chunk cache, but it's completely irrelevant because it's speculative. Calling it compound pages here is a misnomer, and it confuses the discussion. The question is really about whether we should start using higher order allocations for data in the page cache, and perhaps a better way of framing that question is: should we continue to fragment all our page cache allocations up front into individual pages? But I don't think this really the blocker. > 1. Is the folio a good descriptor for all uses of anon and file pages > inside MM code way beyond the page cache layer YOU care about? > > For some people the answers are yes, for others they are a no. The anon page conversion does seem to be where all the disagreement is coming from. So my ask, to everyone involved is - if anonymous pages are dropped from the folio patches, do we have any other real objections to the patch series? It's an open question as to how much anonymous pages are like file pages, and if we continue down the route of of splitting up struct page into separate types whether anonymous pages should be the same time as file pages. Also, it appears even file pages aren't fully converted to folios in Willy's patch set - grepping around reveals plenty of references to struct page left in fs/. I think that even if anonymous pages are going to become folios it's a pretty reasonable ask for that to wait a cycle or two and see how the conversion of file pages fully plays out. Also: it's become pretty clear to me that we have crappy communications between MM developers and filesystem developers. Internally both teams have solid communications - I know in filesystem land we all talk to each other and are pretty good at working colaboratively, and it sounds like the MM team also has good internal communications. But we seem to have some problems with tackling issues that cross over between FS and MM land, or awkwardly sit between them. Perhaps this is something we could try to address when picking conference topics in the future. Johannes also mentioned a monthly group call the MM devs schedule - I wonder if it would be useful to get something similar going between MM and interested parties in filesystem land.