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.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 052C7C47082 for ; Fri, 4 Jun 2021 02:30:17 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 830EB61407 for ; Fri, 4 Jun 2021 02:30:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 830EB61407 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 1AE916B0036; Thu, 3 Jun 2021 22:30:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 15FCA6B006C; Thu, 3 Jun 2021 22:30:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F414A6B006E; Thu, 3 Jun 2021 22:30:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0127.hostedemail.com [216.40.44.127]) by kanga.kvack.org (Postfix) with ESMTP id BD9166B0036 for ; Thu, 3 Jun 2021 22:30:15 -0400 (EDT) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 46DF3181AC9CB for ; Fri, 4 Jun 2021 02:30:15 +0000 (UTC) X-FDA: 78214461990.06.B332A62 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf08.hostedemail.com (Postfix) with ESMTP id 3D0628019895 for ; Fri, 4 Jun 2021 02:29:53 +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=ZJLS4mJyjnY+bHzbPHD0JnHSTH2Mf2XBgDyq2VaF36A=; b=ZK+l8zcISQfWND9zUMSVphN4v6 JIZZgcd/s1pPJpkvkPrf+9sVSWNgiWuj4JAOnv3typNwCuF2jti9P3zEH9R4IojVWDKTqz2qZ0UiT Uf/7kVTz2CTWCmY+RaTYEfSf+3lYLM1cIS/9BOzhg/CajJiaGLRuOgAd4PvQM58sp43SWGJ6QjHm+ RKBoOL5MU+kOCHsvKy26sei6iXxomRN888kWI1LiM8bQSI13MHVBjU0bcG++IaXYxywhzNz1J5aXL wrUpCun5Ltworv8btMQh1n/Y3OPtXbA/SvYzoGF2joG14L5C5uEqsO1zvxG7Zopiq1G74ZPD9ypce O2ygDQLw==; Received: from willy by casper.infradead.org with local (Exim 4.94 #2 (Red Hat Linux)) id 1lozKq-00ClDW-LM; Fri, 04 Jun 2021 02:13:26 +0000 Date: Fri, 4 Jun 2021 03:13:20 +0100 From: Matthew Wilcox To: Matteo Croce Cc: akpm@linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v10 00/33] Memory folios Message-ID: References: <20210511214735.1836149-1-willy@infradead.org> <20210604030712.11b31259@linux.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210604030712.11b31259@linux.microsoft.com> X-Rspamd-Queue-Id: 3D0628019895 Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=ZK+l8zcI; dmarc=none; spf=none (imf08.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org X-Rspamd-Server: rspam03 X-Stat-Signature: n3sz7cd771p1xrhh4podrek7n8kmuyy1 X-HE-Tag: 1622773793-508662 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 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.