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=-16.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS 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 CE295C433ED for ; Tue, 6 Apr 2021 15:14:33 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 40E4661380 for ; Tue, 6 Apr 2021 15:14:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 40E4661380 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id C49096B0081; Tue, 6 Apr 2021 11:14:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C1F666B0082; Tue, 6 Apr 2021 11:14:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AE71B6B0083; Tue, 6 Apr 2021 11:14:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0030.hostedemail.com [216.40.44.30]) by kanga.kvack.org (Postfix) with ESMTP id 92E266B0081 for ; Tue, 6 Apr 2021 11:14:32 -0400 (EDT) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 4F8116D75 for ; Tue, 6 Apr 2021 15:14:32 +0000 (UTC) X-FDA: 78002288784.05.A75B23C Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf18.hostedemail.com (Postfix) with ESMTP id 968592000261 for ; Tue, 6 Apr 2021 15:14:31 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id A0DD561363; Tue, 6 Apr 2021 15:14:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1617722069; bh=6EwsObpnkQ5Dfea7gjpKREYGxQADGcmpX2jhvrqCVvk=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=RmKRdevffH/BmKSNQGh8I3FH7lztg+9RgJlXEMubNtq2LQkdqPgIeqiVpbeayXjli /xc6m1DPIBswndDuw4IpuYW+rmFX8Gmnzzz4yPefsAH4bidLENQzjFxrxJAlb+sEbp ci7sLQ9BOrfpLkOJSHCexaG187bddwVLzZPXL6VtaT+kfVnjk7SG3VGGOrS0GpNR18 xJQC7fZqH4wECX+Aqv411LxhfSIDzc/Wu9YM2aj2oRvWvOBYkV2WgHHW2Pj+3a7cLE r80lUzz3K/EoqaLeXjfNG6yDImXu30o7KlQWWw8WZ2zLbcTlJMTaUk2g4qXImv6PQJ yTJl7LqN1KYaQ== Message-ID: Subject: Re: [PATCH v6 00/27] Memory Folios From: Jeff Layton To: Matthew Wilcox Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-cachefs@redhat.com, linux-afs@lists.infradead.org Date: Tue, 06 Apr 2021 11:14:27 -0400 In-Reply-To: <20210405193120.GL2531743@casper.infradead.org> References: <20210331184728.1188084-1-willy@infradead.org> <759cfbb63ca960b2893f2b879035c2a42c80462d.camel@kernel.org> <20210405193120.GL2531743@casper.infradead.org> Content-Type: text/plain; charset="ISO-8859-15" User-Agent: Evolution 3.38.4 (3.38.4-1.fc33) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 968592000261 X-Stat-Signature: tegisd5nymkt16munu78qkc6m4pdx35k Received-SPF: none (kernel.org>: No applicable sender policy available) receiver=imf18; identity=mailfrom; envelope-from=""; helo=mail.kernel.org; client-ip=198.145.29.99 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1617722071-623481 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 Mon, 2021-04-05 at 20:31 +0100, Matthew Wilcox wrote: > On Mon, Apr 05, 2021 at 03:14:29PM -0400, Jeff Layton wrote: > > On Wed, 2021-03-31 at 19:47 +0100, Matthew Wilcox (Oracle) wrote: > > > Managing memory in 4KiB pages is a serious overhead. Many benchmarks > > > exist which show the benefits of a larger "page size". As an example, > > > an earlier iteration of this idea which used compound pages got a 7% > > > performance boost when compiling the kernel using kernbench without any > > > particular tuning. > > > > > > 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. > > > > > > 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. > > > The term 'nottail' has not proven popular. > > > > > > 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. > > > > > > This series introduces the 'struct folio' as a replacement for > > > head-or-base pages. This initial set reduces the kernel size by > > > approximately 5kB 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. > > > > > > 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 very > > > few conversions from folios when this work is completed; filesystems, > > > the page cache, the LRU and so on will generally only deal with folios. > > > > I too am a little concerned about the amount of churn this is likely to > > cause, but this does seem like a fairly promising way forward for > > actually using THPs in the pagecache. The set is fairly straightforward. > > > > That said, there are few callers of these new functions in here. Is this > > set enough to allow converting some subsystem to use folios? It might be > > good to do that if possible, so we can get an idea of how much work > > we're in for. > > It isn't enough to start converting much. There needs to be a second set > of patches which add all the infrastructure for converting a filesystem. > Then we can start working on the filesystems. I have a start at that > here: > > https://git.infradead.org/users/willy/pagecache.git/shortlog/refs/heads/folio > > I don't know if it's exactly how I'll arrange it for submission. It might > be better to convert all the filesystem implementations of readpage > to work on a folio, and then the big bang conversion of ->readpage to > ->read_folio will look much more mechanical. > > But if I can't convince people that a folio approach is what we need, > then I should stop working on it, and go back to fixing the endless > stream of bugs that the thp-based approach surfaces. Fair enough. I generally prefer to see some callers added at the same time as new functions, but I understand that the scale of this patchset makes that difficult. You can add this to the whole series. I don't see any major show-stoppers here: Acked-by: Jeff Layton