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 ABECFC432BE for ; Fri, 27 Aug 2021 12:06:28 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1D5DE60F6C for ; Fri, 27 Aug 2021 12:06:28 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 1D5DE60F6C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 78B138D0002; Fri, 27 Aug 2021 08:06:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 73B6B8D0001; Fri, 27 Aug 2021 08:06:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 629B38D0002; Fri, 27 Aug 2021 08:06:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0070.hostedemail.com [216.40.44.70]) by kanga.kvack.org (Postfix) with ESMTP id 464138D0001 for ; Fri, 27 Aug 2021 08:06:27 -0400 (EDT) Received: from smtpin34.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id DA8DF1D606 for ; Fri, 27 Aug 2021 12:06:26 +0000 (UTC) X-FDA: 78520733172.34.DB288B8 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf10.hostedemail.com (Postfix) with ESMTP id 4A2BE600199C for ; Fri, 27 Aug 2021 12:06:26 +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=qyXblKfzKi0M/ZBTjKDzsBk5pEo6TqTVKlmSZn0GpDg=; b=pEZAjqyUYEjAckJA/23zaJLAf/ bWCTtj4BqKKt0B2KcE7INS7Lsg4hxcA7XE3jzCZFCfMx9l61IIkuNcEvTo+Z+rZwZc15l6OWNUPKN CIORkmRhnjj4QegdpMEEY8bDm9JJrUei4QbPaqQ+EfPD6zSiO251ROVuqgkkUEoHxq9uVJh2JkPGT hSxCGNPmG6A57KluamQE1Ua9CoKJSOENpEUDSVAnqE+6coWR7cV+Fl1qQyO7PiKENtH4kzunfR239 AVMDF+jP2mNXWRKdJY8f1J16hG/rK4JpUBG6GVytF/Bc7L8LkRomHPJlGhhzt2VGKBjUWiOrkzmga 1Tle5evQ==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1mJac7-00EW7t-BM; Fri, 27 Aug 2021 12:05:47 +0000 Date: Fri, 27 Aug 2021 13:05:39 +0100 From: Matthew Wilcox To: Johannes Weiner Cc: David Howells , Linus Torvalds , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Andrew Morton Subject: Re: [GIT PULL] Memory folios for v5.15 Message-ID: References: <2101397.1629968286@warthog.procyon.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=pEZAjqyU; spf=none (imf10.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 4A2BE600199C X-Stat-Signature: 3sc6ushotg8uoixjdgs5nzi37ecbyc7u X-HE-Tag: 1630065986-638166 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 Fri, Aug 27, 2021 at 06:03:25AM -0400, Johannes Weiner wrote: > At the current stage of conversion, folio is a more clearly delineated > API of what can be safely used from the FS for the interaction with > the page cache and memory management. And it looks still flexible to > make all sorts of changes, including how it's backed by > memory. Compared with the page, where parts of the API are for the FS, > but there are tons of members, functions, constants, and restrictions > due to the page's role inside MM core code. Things you shouldn't be > using, things you shouldn't be assuming from the fs side, but it's > hard to tell which is which, because struct page is a lot of things. > > However, the MM narrative for folios is that they're an abstraction > for regular vs compound pages. This is rather generic. Conceptually, > it applies very broadly and deeply to MM core code: anonymous memory > handling, reclaim, swapping, even the slab allocator uses them. If we > follow through on this concept from the MM side - and that seems to be > the plan - it's inevitable that the folio API will grow more > MM-internal members, methods, as well as restrictions again in the > process. Except for the tail page bits, I don't see too much in struct > page that would not conceptually fit into this version of the folio. So the superhypermegaultra ambitious version of this does something like: struct slab_page { unsigned long flags; union { struct list_head slab_list; struct { ... }; }; struct kmem_cache *slab_cache; void *freelist; void *s_mem; unsigned int active; atomic_t _refcount; unsigned long memcg_data; }; struct folio { ... more or less as now ... }; struct net_page { unsigned long flags; unsigned long pp_magic; struct page_pool *pp; unsigned long _pp_mapping_pad; unsigned long dma_addr[2]; atomic_t _mapcount; atomic_t _refcount; unsigned long memcg_data; }; struct page { union { struct folio folio; struct slab_page slab; struct net_page pool; ... }; }; and then functions which only take one specific type of page use that type. And the compiler will tell you that you can't pass a net_page to a slab function, or vice versa. This is a lot more churn, and I'm far from convinced that it's worth doing. There's also the tricky "This page is mappable to userspace" kind of functions, which (for example) includes vmalloc and net_page as well as folios and random driver allocations, but shouldn't include slab or page table pages. They're especially tricky because mapping to userspace comes with rules around the use of the ->mapping field as well as ->_mapcount.