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=-6.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 7CC1AC4338F for ; Tue, 24 Aug 2021 15:54:36 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 19C6561212 for ; Tue, 24 Aug 2021 15:54:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 19C6561212 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 602EA6B006C; Tue, 24 Aug 2021 11:54:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5B2BB6B0071; Tue, 24 Aug 2021 11:54:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 47AED8D0001; Tue, 24 Aug 2021 11:54:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0085.hostedemail.com [216.40.44.85]) by kanga.kvack.org (Postfix) with ESMTP id 2D6826B006C for ; Tue, 24 Aug 2021 11:54:35 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 592928249980 for ; Tue, 24 Aug 2021 15:54:34 +0000 (UTC) X-FDA: 78510421668.27.0205B31 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf22.hostedemail.com (Postfix) with ESMTP id 07D981906 for ; Tue, 24 Aug 2021 15:54:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1629820473; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ax6zjB8FCNgsQYLqgNFMq9OeoawxxmOPV3+aTibAsX4=; b=fI365UceJ5KD1PaRVcgO5HYvvwqnHdxAImOE7ttzSwOmrm+4gF3qmobC+Sitk0WrTyL/Rj YSLpVw0e/t67la/gCv3CLBp9uYU0zIFqbyN9cBIXVf4pd4hZYxiK/OnyUIGU6peLpHxVb5 0eMYqbKT3V5hrZ4EjnJh8wSSjhhOfEE= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-34-sL2lRNboPTWorPFJiNMLBA-1; Tue, 24 Aug 2021 11:54:32 -0400 X-MC-Unique: sL2lRNboPTWorPFJiNMLBA-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 92BDA800493; Tue, 24 Aug 2021 15:54:30 +0000 (UTC) Received: from warthog.procyon.org.uk (unknown [10.33.36.86]) by smtp.corp.redhat.com (Postfix) with ESMTP id AA77A10016F5; Tue, 24 Aug 2021 15:54:28 +0000 (UTC) Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 From: David Howells In-Reply-To: References: To: Linus Torvalds Cc: dhowells@redhat.com, Johannes Weiner , Matthew Wilcox , Linux-MM , linux-fsdevel , Linux Kernel Mailing List , Andrew Morton Subject: Re: [GIT PULL] Memory folios for v5.15 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1957059.1629820467.1@warthog.procyon.org.uk> Date: Tue, 24 Aug 2021 16:54:27 +0100 Message-ID: <1957060.1629820467@warthog.procyon.org.uk> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=fI365Uce; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf22.hostedemail.com: domain of dhowells@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=dhowells@redhat.com X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 07D981906 X-Stat-Signature: aw3m3xpf9x5y8b5uxn1gg7txbm3t3a9u X-HE-Tag: 1629820473-426911 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: Linus Torvalds wrote: > Yeah, honestly, I would have preferred to see this done the exact > reverse way: make the rule be that "struct page" is always a head > page, and anything that isn't a head page would be called something > else. > ... > That said, I see why Willy did it the way he did - it was easier to do > it incrementally the way he did. But I do think it ends up with an end > result that is kind of topsy turvy where the common "this is the core > allocation" being called that odd "folio" thing, and then the simpler > "page" name is for things that almost nobody should even care about. >From a filesystem pov, it may be better done Willy's way. There's a lot of assumption that "struct page" corresponds to a PAGE_SIZE patch of RAM and is equivalent to a hardware page, so using something other than struct page seems a better idea. It's easier to avoid the assumption if it's called something different. We're dealing with variable-sized clusters of things that, in the future, could be, say, a combination of typical 4K pages and higher order pages (depending on what the arch supports), so I think using "page" is the wrong name to use. There are some pieces, kmap being a prime example, that might be tricky to make handle a transparently variable-sized multipage object, so careful auditing will likely be required if we do stick with "struct page". Further, there's the problem that there are a *lot* of places where filesystems access struct page members directly, rather than going through helper functions - and all of these need to be fixed. This is much easier to manage if we can get the compiler to do the catching. Hiding them all within struct page would require a humongous single patch. One question does spring to mind, though: do filesystems even need to know about hardware pages at all? They need to be able to access source data or a destination buffer, but that can be stitched together from disparate chunks that have nothing to do with pages (eg. iov_iter); they need access to the pagecache, and may need somewhere to cache pieces of information, and they need to be able to pass chunks of pagecache, data or bufferage to crypto (scatterlists) and I/O routines (bio, skbuff) - but can we hide "paginess" from filesystems? The main point where this matters, at the moment, is, I think, mmap - but could more of that be handled transparently by the VM? > Because, as you say, head pages are the norm. And "folio" may be a > clever term, but it's not very natural. Certainly not at all as > intuitive or common as "page" as a name in the industry. That's mostly because no one uses the term... yet, and that it's not commonly used. I've got used to it in building on top of Willy's patches and have no problem with it - apart from the fact that I would expect something more like a plural or a collective noun ("sheaf" or "ream" maybe?) - but at least the name is similar in length to "page". And it's handy for grepping ;-) > I'd have personally preferred to call the head page just a "page", and > other pages "subpage" or something like that. I think that would be > much more intuitive than "folio/page". As previously stated, I think we need to leave "struct page" as meaning "hardware page" and build some other concept on top for aggregation/buffering. David