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=-7.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,MENTIONS_GIT_HOSTING, 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 C2D6CC43461 for ; Sat, 1 May 2021 01:32:28 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 448E4613EA for ; Sat, 1 May 2021 01:32:28 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 448E4613EA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 4A2C76B006C; Fri, 30 Apr 2021 21:32:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 452FE6B006E; Fri, 30 Apr 2021 21:32:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2CD8E6B0070; Fri, 30 Apr 2021 21:32:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0220.hostedemail.com [216.40.44.220]) by kanga.kvack.org (Postfix) with ESMTP id 0F1366B006C for ; Fri, 30 Apr 2021 21:32:27 -0400 (EDT) Received: from smtpin36.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id BC3CC8249980 for ; Sat, 1 May 2021 01:32:26 +0000 (UTC) X-FDA: 78090937092.36.0165674 Received: from mail-pj1-f47.google.com (mail-pj1-f47.google.com [209.85.216.47]) by imf01.hostedemail.com (Postfix) with ESMTP id 60840500153A for ; Sat, 1 May 2021 01:32:17 +0000 (UTC) Received: by mail-pj1-f47.google.com with SMTP id f6-20020a17090a6546b029015088cf4a1eso258366pjs.2 for ; Fri, 30 Apr 2021 18:32:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:subject:to:cc:references:in-reply-to:mime-version :message-id:content-transfer-encoding; bh=A2A0sc0ibpGRObArrf856v6artvUyLBvrSP/rauEHZM=; b=dTdzE/ywka9nrPdX+QwFz6j9UB51qNNcagD7P92W4OSxbEerkeF+CUzs5nF07mGi9v RfvzodgfrTFRe7e/45aajNmewKM4Aox8rz84W2WO311ZE4+h4dDpTToeGJWG2h7yw5O8 KTD+beFgdQkbWlSnx7RLiLrD1X9Gf3+Taqf1HZVUz9Yk0FCHxr7U94P0yuDa41V1scHe Quk1/dAv9rBITiUL/x2C+F0ZvAHMz1mI78zOWL/ffb7csu/k5GlmUllqexjtrPiAKR4Z J2Nh7R8nrNSHDMJlXINfSOZPoPWplFH1x64oEuKPU/xSt4s8iad6dMKibYp9e6kbyrXI Z6gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:subject:to:cc:references:in-reply-to :mime-version:message-id:content-transfer-encoding; bh=A2A0sc0ibpGRObArrf856v6artvUyLBvrSP/rauEHZM=; b=EF2vf0bcHWicJ1AOoNJLIGkZfOsuuD3/xYkIwTbbxSecGmIdjUpIIU+wQJcIGu68eF ijkhZKQfAf5OzrP7VGPBJXg4XkBDzmZsmIqcEAow9POdx+k2vBMMGThNHmXKZHYOmfb/ 96vzAfDPi/RBiMCuP/7CdDLto1mNWHynZgBXDetU+H1umhTAENqmWVIcGFHLgjCVYYsB gco/uvCbAF8NFXrZHvq0JGCAmxUAuOWyV5DBS92l7BwJfSdJZFiUV9uKRQWyvUoshYdD aJrzHqgragIxoD2WxWwv6F03+ZSUvRju2PTDG24UNTKOurBy2bL8GusAnwI+odoAi/ey Z+0w== X-Gm-Message-State: AOAM533wX8XswIv6jXWaYXFyiU76d89gf8HAG/jQ377IZnJYooRl6TUC gBpnj3CNbyE5RvjjBbAcgIc= X-Google-Smtp-Source: ABdhPJz3GeJE6oOuurnasV8V+UQQcA8JLk4FTbqtTR91l8SpVcMKLWi5PaLuQ8u2hIX6JuhWMNYWdQ== X-Received: by 2002:a17:90a:de09:: with SMTP id m9mr7830662pjv.41.1619832745434; Fri, 30 Apr 2021 18:32:25 -0700 (PDT) Received: from localhost ([61.68.127.20]) by smtp.gmail.com with ESMTPSA id w14sm3279317pfn.3.2021.04.30.18.32.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 30 Apr 2021 18:32:25 -0700 (PDT) Date: Sat, 01 May 2021 11:32:20 +1000 From: Nicholas Piggin Subject: Re: [PATCH v8.1 00/31] Memory Folios To: Hugh Dickins , "Matthew Wilcox (Oracle)" Cc: akpm@linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, Linus Torvalds References: <20210430180740.2707166-1-willy@infradead.org> In-Reply-To: MIME-Version: 1.0 Message-Id: <1619832406.8taoh84cay.astroid@bobo.none> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 60840500153A Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20161025 header.b="dTdzE/yw"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf01.hostedemail.com: domain of npiggin@gmail.com designates 209.85.216.47 as permitted sender) smtp.mailfrom=npiggin@gmail.com X-Stat-Signature: j8bpjbzzqnzjsmdo77gezxb3f6q4qizx Received-SPF: none (gmail.com>: No applicable sender policy available) receiver=imf01; identity=mailfrom; envelope-from=""; helo=mail-pj1-f47.google.com; client-ip=209.85.216.47 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1619832737-52770 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: Excerpts from Hugh Dickins's message of May 1, 2021 4:47 am: > Adding Linus to the Cc (of this one only): he surely has an interest. >=20 > On Fri, 30 Apr 2021, Matthew Wilcox (Oracle) wrote: >=20 >> Managing memory in 4KiB pages is a serious overhead. Many benchmarks >> benefit from a larger "page size". As an example, an earlier iteration >> of this idea which used compound pages (and wasn't particularly tuned) >> got a 7% performance boost when compiling the kernel. >>=20 >> Using compound pages or THPs exposes a serious weakness in our type >> system. Functions are often unprepared for compound pages to be passed >> to them, and may only act on PAGE_SIZE chunks. Even functions which are >> aware of compound pages may expect a head page, and do the wrong thing >> if passed a tail page. >>=20 >> There have been efforts to label function parameters as 'head' instead >> of 'page' to indicate that the function expects a head page, but this >> leaves us with runtime assertions instead of using the compiler to prove >> that nobody has mistakenly passed a tail page. Calling a struct page >> 'head' is also inaccurate as they will work perfectly well on base pages= . >>=20 >> We also waste a lot of instructions ensuring that we're not looking at >> a tail page. Almost every call to PageFoo() contains one or more hidden >> calls to compound_head(). This also happens for get_page(), put_page() >> and many more functions. There does not appear to be a way to tell gcc >> that it can cache the result of compound_head(), nor is there a way to >> tell it that compound_head() is idempotent. >>=20 >> This series introduces the 'struct folio' as a replacement for >> head-or-base pages. This initial set reduces the kernel size by >> approximately 6kB by removing conversions from tail pages to head pages. >> The real purpose of this series is adding infrastructure to enable >> further use of the folio. >>=20 >> The medium-term goal is to convert all filesystems and some device >> drivers to work in terms of folios. This series contains a lot of >> explicit conversions, but it's important to realise it's removing a lot >> of implicit conversions in some relatively hot paths. There will be ver= y >> few conversions from folios when this work is completed; filesystems, >> the page cache, the LRU and so on will generally only deal with folios. >>=20 >> The text size reduces by between 6kB (a config based on Oracle UEK) >> and 1.2kB (allnoconfig). Performance seems almost unaffected based >> on kernbench. >>=20 >> Current tree at: >> https://git.infradead.org/users/willy/pagecache.git/shortlog/refs/heads/= folio >>=20 >> (contains another ~120 patches on top of this batch, not all of which ar= e >> in good shape for submission) >>=20 >> v8.1: >> - Rebase on next-20210430 >> - You need https://lore.kernel.org/linux-mm/20210430145549.2662354-1-wi= lly@infradead.org/ first >> - Big renaming (thanks to peterz): >> - PageFoo() becomes folio_foo() >> - SetFolioFoo() becomes folio_set_foo() >> - ClearFolioFoo() becomes folio_clear_foo() >> - __SetFolioFoo() becomes __folio_set_foo() >> - __ClearFolioFoo() becomes __folio_clear_foo() >> - TestSetPageFoo() becomes folio_test_set_foo() >> - TestClearPageFoo() becomes folio_test_clear_foo() >> - PageHuge() is now folio_hugetlb() If you rename these things at the same time, can you make it clear=20 they're flags (folio_flag_set_foo())? The weird camel case accessors at=20 least make that clear (after you get to know them). We have a set_page_dirty(), so page_set_dirty() would be annoying. page_flag_set_dirty() keeps the easy distinction that SetPageDirty() provides. Thanks, Nick