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 0E718C433ED for ; Wed, 31 Mar 2021 14:55:48 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 677BD61008 for ; Wed, 31 Mar 2021 14:55:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 677BD61008 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 E53876B0085; Wed, 31 Mar 2021 10:55:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DB5586B0089; Wed, 31 Mar 2021 10:55:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C580C6B008A; Wed, 31 Mar 2021 10:55:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0211.hostedemail.com [216.40.44.211]) by kanga.kvack.org (Postfix) with ESMTP id A1A486B0085 for ; Wed, 31 Mar 2021 10:55:46 -0400 (EDT) Received: from smtpin38.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 59CE28249980 for ; Wed, 31 Mar 2021 14:55:46 +0000 (UTC) X-FDA: 77980468692.38.1090CD3 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf06.hostedemail.com (Postfix) with ESMTP id A26CDC0007C9 for ; Wed, 31 Mar 2021 14:55:45 +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=WOGmEDTpzeV+1sPuo1/4FzQmK0Bbmt6+Hd4kBlUeNn4=; b=ezANnEEwtA3WVH3yRzdT3IIjm/ hPtAZF+uX9BQ9Vf2DrfCxXGMegOYtEXonVofV18ODNEHrWv3451OJ112lzliorOZbgp5VD8aQsQOU +hsiY3qspYBznIjxtmxCq0zjTC+dYgqfwkjWpuhvrV9Cvxn+CWE9ahveEsJIelBybB4kdDgTU7P0s 9bhLA8ioXyMoS+42FX8qW9gfNFBPspwG++LKkfETXQAbGFPBCnLAPKtj3KI42xW0pCdcQnZXSzwoA 27gLDyTtu9P5QiKxZQ/PxhM/iy/P4asC8Bun2EYeEufke2SERIYy+bmUulTkkUEjQ7+qKkjeLsDD+ 4ETENptA==; Received: from hch by casper.infradead.org with local (Exim 4.94 #2 (Red Hat Linux)) id 1lRcEh-004hdF-5c; Wed, 31 Mar 2021 14:54:35 +0000 Date: Wed, 31 Mar 2021 15:54:23 +0100 From: Christoph Hellwig To: Johannes Weiner Cc: Matthew Wilcox , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-cachefs@redhat.com, linux-afs@lists.infradead.org Subject: Re: [PATCH v5 00/27] Memory Folios Message-ID: <20210331145423.GA1118729@infradead.org> References: <20210320054104.1300774-1-willy@infradead.org> <20210322184744.GU1719932@casper.infradead.org> <20210324062421.GQ1719932@casper.infradead.org> <20210329165832.GG351017@casper.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-SRS-Rewrite: SMTP reverse-path rewritten from by casper.infradead.org. See http://www.infradead.org/rpr.html X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: A26CDC0007C9 X-Stat-Signature: n4bzt7wcwqwfj9extpxkjnu386ap4ggz Received-SPF: none (casper.srs.infradead.org>: No applicable sender policy available) receiver=imf06; identity=mailfrom; envelope-from=""; helo=casper.infradead.org; client-ip=90.155.50.34 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1617202545-800190 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, Mar 30, 2021 at 03:30:54PM -0400, Johannes Weiner wrote: > > Eventually, I want to make struct page optional for allocations. It's too > > small for some things (allocating page tables, for example), and overly > > large for others (allocating a 2MB page, networking page_pool). I don't > > want to change its size in the meantime; having a struct page refer to > > PAGE_SIZE bytes is something that's quite deeply baked in. > > Right, I think it's overloaded and it needs to go away from many > contexts it's used in today. FYI, one unrelated usage is that in many contet we use a struct page and an offset to describe locations for I/O (block layer, networking, DMA API). With huge pages and merged I/O buffers this representation actually becomes increasingly painful. And a little bit back to the topic: I think the folio as in the current patchset is incredibly useful and someting we need like yesterday to help file systems and the block layer to cope with huge and compound pages of all sorts. Once willy sends out a new version with the accumulated fixes I'm ready to ACK the whole thing.