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.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 AF632C07E99 for ; Mon, 12 Jul 2021 11:36:20 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 418A261151 for ; Mon, 12 Jul 2021 11:36:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 418A261151 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 302FB6B009D; Mon, 12 Jul 2021 07:36:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2DAA28D0001; Mon, 12 Jul 2021 07:36:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1A2886B00A1; Mon, 12 Jul 2021 07:36:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0206.hostedemail.com [216.40.44.206]) by kanga.kvack.org (Postfix) with ESMTP id E65F36B009D for ; Mon, 12 Jul 2021 07:36:19 -0400 (EDT) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 087E4184A7700 for ; Mon, 12 Jul 2021 11:36:19 +0000 (UTC) X-FDA: 78353732478.29.BD2F4F5 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf08.hostedemail.com (Postfix) with ESMTP id 32E2E30000AB for ; Mon, 12 Jul 2021 11:36:18 +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=D5qx3dVKgrH7eIQyjcDlzzDy7QOQdnxbowoXaJPlgMg=; b=iblrGfKdeb6Ro1mum0SxNGam0d omVYWRsSb97CvbeOIJvvAlaDSBTMePy5R9s/R4m5pUq4MFYqa+WPxpSHStpTmiCaWOQUpmJL2FrlT d8yEVAcmAeiik2gIVICzs+BMVab1AVPku6G1jjkYwF3Az6+bjtrGfjbDV4ICBtV0Lh3DNv/29dPnH nofbAeZ+HSKFzkDxOAy9OcN7uyjGm3LN7WukrdmYul2G5ed44zzN/ucmvq65RG2hz2SH7WaHYKJ9U SBv8crZhOC4WA0PjOPwOY+j3oud3NG4H0QgW+wZYzAk5rgBpesPt2Xc3ErC8eN7BnD6CpRCZ046w5 oyPCjVxQ==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1m2uE7-00HYKa-C6; Mon, 12 Jul 2021 11:36:01 +0000 Date: Mon, 12 Jul 2021 12:35:55 +0100 From: Matthew Wilcox To: Christoph Hellwig Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH v13 000/137] Memory folios Message-ID: References: <20210712030701.4000097-1-willy@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=iblrGfKd; 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; dmarc=none X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 32E2E30000AB X-Stat-Signature: 5ebz75t57ioymk8tp17qe455r4jch1su X-HE-Tag: 1626089778-504935 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, Jul 12, 2021 at 06:46:05AM +0100, Christoph Hellwig wrote: > On Mon, Jul 12, 2021 at 04:04:44AM +0100, Matthew Wilcox (Oracle) wrote: > > 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. > > > > Using compound pages or THPs exposes a weakness of 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. > > > > 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. > > > > This patch series uses a new type, the struct folio, to manage memory. > > It converts enough of the page cache, iomap and XFS to use folios instead > > of pages, and then adds support for multi-page folios. It passes xfstests > > (running on XFS) with no regressions compared to v5.14-rc1. > > This seems to miss a changelog vs the previous version. It also > includes a lot of the follow ups. I think reviewing a series gets > rather hard at more than 30-ish patches, so chunking it up a little > more would be useful. I'm not seriously expecting anybody to review 137 patches. It's more for the bots to chew on (which they have done and I'm about to look at their output). I'll be sending mergable subsets (three rounds; the base code, the memcg series and the pagecache series) later this week, once I've addressed the build bot complaints. You've seen all those patches individually by now. My plan is that once those are merged, the rest can proceed in parallel. The block + iomap series is independent, then there's the second pagecache series. The last dozen or so patches still need a bit of work as they were pulled across from the THP tree and at least need better changelogs. Since this works for me, I'm hoping some people will also test and confirm it works for them, and maybe post their own performance numbers to justify all this.