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=-18.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL autolearn=ham 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 BFC29C4743D for ; Tue, 8 Jun 2021 14:57:02 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3FBB960233 for ; Tue, 8 Jun 2021 14:57:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3FBB960233 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.microsoft.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A79566B006C; Tue, 8 Jun 2021 10:57:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A297C6B006E; Tue, 8 Jun 2021 10:57:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8CA256B0070; Tue, 8 Jun 2021 10:57:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0019.hostedemail.com [216.40.44.19]) by kanga.kvack.org (Postfix) with ESMTP id 587B26B006C for ; Tue, 8 Jun 2021 10:57:01 -0400 (EDT) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id EED10180AD80F for ; Tue, 8 Jun 2021 14:57:00 +0000 (UTC) X-FDA: 78230859000.20.16B18CE Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by imf15.hostedemail.com (Postfix) with ESMTP id 05955A000264 for ; Tue, 8 Jun 2021 14:56:59 +0000 (UTC) Received: from mail-pj1-f46.google.com (mail-pj1-f46.google.com [209.85.216.46]) by linux.microsoft.com (Postfix) with ESMTPSA id 54EA020B7188 for ; Tue, 8 Jun 2021 07:56:59 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 54EA020B7188 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1623164219; bh=5adkBab5YgC4ua7cy6g3IJlMevjI3rkkXDpAoANH9ho=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=BaXOma7rHPHFSCxmGUeLjFRe22Dav9/8UdX+EwMLhxCiIfkKRd9/FnXM4JLfKnnCz 143ihX/qoVP5IyJq6KydhH+lUN8bDRzB4bP2jupk6lQ6rDocZXtFtf1OmunaiwTTqg 3eyIEW7OcCiSKjGRMAJFitXJgFUZEYz6MXLPayZc= Received: by mail-pj1-f46.google.com with SMTP id g4so2604666pjk.0 for ; Tue, 08 Jun 2021 07:56:59 -0700 (PDT) X-Gm-Message-State: AOAM530MKeFgHOXUowILlhqdJGtuTpxZkB4BmGTUCjoAu7py89GOVBEo dR7FH1I/u/odWrk0fdNPopljdAB35mhn3ocUAoU= X-Google-Smtp-Source: ABdhPJzNnGHBMRnqD7hcfQnkP4ftZvW9/ffkse696Bzy4x7VTQyeIyWA6fK1974zMmVl3AKfQy85iM5JjczuDF0rpu8= X-Received: by 2002:a17:90b:109:: with SMTP id p9mr5359058pjz.11.1623164218966; Tue, 08 Jun 2021 07:56:58 -0700 (PDT) MIME-Version: 1.0 References: <20210511214735.1836149-1-willy@infradead.org> <20210604030712.11b31259@linux.microsoft.com> In-Reply-To: From: Matteo Croce Date: Tue, 8 Jun 2021 16:56:23 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v10 00/33] Memory folios To: Matthew Wilcox Cc: Andrew Morton , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=linux.microsoft.com header.s=default header.b=BaXOma7r; spf=pass (imf15.hostedemail.com: domain of mcroce@linux.microsoft.com designates 13.77.154.182 as permitted sender) smtp.mailfrom=mcroce@linux.microsoft.com; dmarc=pass (policy=none) header.from=linux.microsoft.com X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 05955A000264 X-Stat-Signature: m67pcybizn5o7y5a4gziqy1gesxtexd8 X-HE-Tag: 1623164219-409110 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, Jun 4, 2021 at 4:13 AM Matthew Wilcox wrote: > > On Fri, Jun 04, 2021 at 03:07:12AM +0200, Matteo Croce wrote: > > On Tue, 11 May 2021 22:47:02 +0100 > > "Matthew Wilcox (Oracle)" wrote: > > > > > 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. > > > > > > > Maybe it's not effective in all situations but the following hint to > > the compiler seems to have an effect, at least according to bloat-o-meter: > > It definitely has an effect ;-) > > Note that a function that has pointer arguments and examines the > data pointed to must _not_ be declared 'const' if the pointed-to > data might change between successive invocations of the function. > In general, since a function cannot distinguish data that might > change from data that cannot, const functions should never take > pointer or, in C++, reference arguments. Likewise, a function that > calls a non-const function usually must not be const itself. > > So that's not going to work because a call to split_huge_page() won't > tell the compiler that it's changed. > > Reading the documentation, we might be able to get away with marking the > function as pure: > > The 'pure' attribute imposes similar but looser restrictions on a > function's definition than the 'const' attribute: 'pure' allows the > function to read any non-volatile memory, even if it changes in > between successive invocations of the function. > > although that's going to miss opportunities, since taking a lock will > modify the contents of struct page, meaning the compiler won't cache > the results of compound_head(). > > > $ scripts/bloat-o-meter vmlinux.o.orig vmlinux.o > > add/remove: 3/13 grow/shrink: 65/689 up/down: 21080/-198089 (-177009) > > I assume this is an allyesconfig kernel? I think it's a good > indication of how much opportunity there is. > Yes, it's an allyesconfig kernel. I did the same with pure: $ git diff diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h index 04a34c08e0a6..548b72b46eb1 100644 --- a/include/linux/page-flags.h +++ b/include/linux/page-flags.h @@ -179,7 +179,7 @@ enum pageflags { struct page; /* forward declaration */ -static inline struct page *compound_head(struct page *page) +static inline __pure struct page *compound_head(struct page *page) { unsigned long head = READ_ONCE(page->compound_head); $ scripts/bloat-o-meter vmlinux.o.orig vmlinux.o add/remove: 3/13 grow/shrink: 63/689 up/down: 20910/-192081 (-171171) Function old new delta ntfs_mft_record_alloc 14414 16627 +2213 migrate_pages 8891 10819 +1928 ext2_get_page.isra 1029 2343 +1314 kfence_init 180 1331 +1151 page_remove_rmap 754 1893 +1139 f2fs_fsync_node_pages 4378 5406 +1028 [...] migrate_page_states 7088 4842 -2246 ntfs_mft_record_format 2940 - -2940 lru_deactivate_file_fn 9220 6277 -2943 shrink_page_list 20653 15749 -4904 page_memcg 5149 193 -4956 Total: Before=388869713, After=388698542, chg -0.04% $ ls -l vmlinux.o.orig vmlinux.o -rw-rw-r-- 1 mcroce mcroce 1295502680 Jun 8 16:47 vmlinux.o -rw-rw-r-- 1 mcroce mcroce 1295934624 Jun 8 16:28 vmlinux.o.orig vmlinux is ~420 kb smaller.. -- per aspera ad upstream