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=-8.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 25DB9C433C1 for ; Mon, 22 Mar 2021 03:54:42 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7EF5261968 for ; Mon, 22 Mar 2021 03:54:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7EF5261968 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 389C86B0036; Sun, 21 Mar 2021 23:35:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 360F16B006C; Sun, 21 Mar 2021 23:35:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1DD476B0072; Sun, 21 Mar 2021 23:35:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0191.hostedemail.com [216.40.44.191]) by kanga.kvack.org (Postfix) with ESMTP id F34CF6B0036 for ; Sun, 21 Mar 2021 23:35:49 -0400 (EDT) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 5FD6A1802914B for ; Mon, 22 Mar 2021 03:54:40 +0000 (UTC) X-FDA: 77946143520.18.5D33949 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf18.hostedemail.com (Postfix) with ESMTP id D3BF72000248 for ; Mon, 22 Mar 2021 03:54:39 +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=OLtU7Po7VDleXiwD97Raw3xEmeFq1dvrerQKytpuzyI=; b=j8ZYytoWWkgXlT3z1roEGsgEli X8fmlr/of840tbaO/jZpc2gZP06Ecym1Zhug/4i/qUs+3rDAEmRcT0cGCkwNliyn7MxBftcvmQ49D FcVsViHszMUACH5uW1YoCXUkwvX3xvzKuVsbjNA3HGeNgRIUPGKSWGWcqEWxyX9IpZrr3u96u6G3I HMaAsHz1MqkmoCm02b1TCdVMTin1nuzF8FxE2gu2+800xhcFZhkTSIhNkTRGDpe8wQ2KUzXP1wsss s5b2BFqqO4CmvreJskvLORGpSNR3uU0h4Ys9LqvKr0oVq76Gr6FvDYJpD/pk4AKy4mVDazyKykhMi qYKChQFg==; Received: from willy by casper.infradead.org with local (Exim 4.94 #2 (Red Hat Linux)) id 1lOBe1-007xJI-Kw; Mon, 22 Mar 2021 03:54:25 +0000 Date: Mon, 22 Mar 2021 03:54:21 +0000 From: Matthew Wilcox To: Nicholas Piggin Cc: Balbir Singh , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v4 01/25] mm: Introduce struct folio Message-ID: <20210322035421.GF1719932@casper.infradead.org> References: <20210305041901.2396498-1-willy@infradead.org> <20210305041901.2396498-2-willy@infradead.org> <20210318235645.GB3346@balbir-desktop> <20210319012527.GX3420@casper.infradead.org> <1616381339.fjexi9aqhl.astroid@bobo.none> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1616381339.fjexi9aqhl.astroid@bobo.none> X-Stat-Signature: 11qrwyq616z6hew9dohbzmh83er9jgb9 X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: D3BF72000248 Received-SPF: none (infradead.org>: No applicable sender policy available) receiver=imf18; identity=mailfrom; envelope-from=""; helo=casper.infradead.org; client-ip=90.155.50.34 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1616385279-703055 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, Mar 22, 2021 at 12:52:40PM +1000, Nicholas Piggin wrote: > Excerpts from Matthew Wilcox's message of March 19, 2021 11:25 am: > > On Fri, Mar 19, 2021 at 10:56:45AM +1100, Balbir Singh wrote: > >> On Fri, Mar 05, 2021 at 04:18:37AM +0000, Matthew Wilcox (Oracle) wrote: > >> > A struct folio refers to an entire (possibly compound) page. A function > >> > which takes a struct folio argument declares that it will operate on the > >> > entire compound page, not just PAGE_SIZE bytes. In return, the caller > >> > guarantees that the pointer it is passing does not point to a tail page. > >> > > >> > >> Is this a part of a larger use case or general cleanup/refactor where > >> the split between page and folio simplify programming? > > > > The goal here is to manage memory in larger chunks. Pages are now too > > small for just about every workload. Even compiling the kernel sees a 7% > > performance improvement just by doing readahead using relatively small > > THPs (16k-256k). You can see that work here: > > https://git.infradead.org/users/willy/pagecache.git/shortlog/refs/heads/master > > The 7% improvement comes from cache cold kbuild by improving IO > patterns? > > Just wondering what kind of readahead is enabled by this that can't > be done with base page size. I see my explanation earlier was confusing. What I meant to say was that the only way in that patch set to create larger pages was at readahead time. Writes were incapable of creating larger pages. Once pages were in the page cache, they got managed at that granularity unless they got split by a truncate/holepunch/io-error/... I don't have good perf runs of kernbench to say exactly where we got the benefit. My assumption is that because we're managing an entire, say, 256kB page as a single unit on the LRU list, we benefit from lower LRU lock contention. There's also the benefit of batching, eg, allocating a single 256kB page from the page allocator may well be more effective than allocating 64 4kB pages.