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 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 404A7C433E0 for ; Fri, 19 Mar 2021 01:26:12 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3453E64E04 for ; Fri, 19 Mar 2021 01:26:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3453E64E04 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 B1BEF6B006C; Thu, 18 Mar 2021 21:26:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AF2F76B006E; Thu, 18 Mar 2021 21:26:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 96C016B0071; Thu, 18 Mar 2021 21:26:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0026.hostedemail.com [216.40.44.26]) by kanga.kvack.org (Postfix) with ESMTP id 760766B006C for ; Thu, 18 Mar 2021 21:26:10 -0400 (EDT) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 382AE18140B82 for ; Fri, 19 Mar 2021 01:26:10 +0000 (UTC) X-FDA: 77934882900.23.113BB03 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf27.hostedemail.com (Postfix) with ESMTP id 94526801914D for ; Fri, 19 Mar 2021 01:26:02 +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=epBGpvSKb5BDsLBUPy9iK8A8YY2xiMLqJ0JDHh+J84k=; b=XW4/4ZnjAQWR2NFfKClgD4ZoY2 PJuV2K+Y/67OJuM7CtWJFtFESWrV+JySdZFUEhNiM9v3CB7NbORoUpKrqC0U+vn56u+Kkwbt9nkwh aizAHFmrE6htQAFPOc6PR7x1V7yjZ0yTkiZwxSfihm42sLR1saFEXmCGIYyUimzLx39yz8BPsQfmC VUNpuRAguPJDAeISfRleO2cZ1mJmd3Wa999ryMFw40fMOFlPnIeo+TmhCh6NiNw+3u/sNghoUfDDM FeaVq4f+rABkPUkse9K1LezlIo9yz9YMn7dXgruKU6kv20P4Vamt9MmVcSFhHl2hEg6GeTQD4vGgo aTyR5bQw==; Received: from willy by casper.infradead.org with local (Exim 4.94 #2 (Red Hat Linux)) id 1lN3tH-003k0x-JB; Fri, 19 Mar 2021 01:25:30 +0000 Date: Fri, 19 Mar 2021 01:25:27 +0000 From: Matthew Wilcox To: Balbir Singh Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH v4 01/25] mm: Introduce struct folio Message-ID: <20210319012527.GX3420@casper.infradead.org> References: <20210305041901.2396498-1-willy@infradead.org> <20210305041901.2396498-2-willy@infradead.org> <20210318235645.GB3346@balbir-desktop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210318235645.GB3346@balbir-desktop> X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 94526801914D X-Stat-Signature: churs5csff71ms478my7bwkgszudqjo6 Received-SPF: none (infradead.org>: No applicable sender policy available) receiver=imf27; identity=mailfrom; envelope-from=""; helo=casper.infradead.org; client-ip=90.155.50.34 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1616117162-73967 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, 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 I think Kirill, Hugh and others have done a fantastic job stretching the page struct to work in shmem, but we really need a different type to avoid people writing code that _looks_ right but is actually buggy. So I'm starting again, this time with the folio metaphor.