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=-12.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 0C970C07E95 for ; Tue, 20 Jul 2021 10:54:47 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id AD5DA6108B for ; Tue, 20 Jul 2021 10:54:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AD5DA6108B 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 583426B00A8; Tue, 20 Jul 2021 06:54:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 50CA46B00A9; Tue, 20 Jul 2021 06:54:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3AD236B00C8; Tue, 20 Jul 2021 06:54:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0138.hostedemail.com [216.40.44.138]) by kanga.kvack.org (Postfix) with ESMTP id 0E7856B00A8 for ; Tue, 20 Jul 2021 06:54:47 -0400 (EDT) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 97A8A8248047 for ; Tue, 20 Jul 2021 10:54:45 +0000 (UTC) X-FDA: 78382658130.09.48B2E44 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf05.hostedemail.com (Postfix) with ESMTP id 5132750135BA for ; Tue, 20 Jul 2021 10:54:45 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id E9884600D4; Tue, 20 Jul 2021 10:54:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1626778484; bh=Ja1be3usDDuv2HFqu3UdV/HBuywqhaiWMGjarNGVSxk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=oWbtO1C6ssjAl8A8/TUy/4MJ+D1+YoxtieXKimAg3Y0aNz/BxIr4OL51uig3Z0R38 9N/y6VfgbnrSv6m37Yv8NVUcPWiXZxSlp44ndQrVI7oyLILn/zFwfE/Jh590iVcvSg veQZQULOIw0j84/xUVkXbaycXmF5XblA24XmXwZWKkkXnhO0NGLwwkJrqX+NTWYUcb OE8yBrczsTk2CZ1ehs19FGfP2q00tq+aJVZDOqZZST0zXqof/50gufNvlZs42UJrYd mXbCZjpVe14qY5Gjxom3PFf9gtJooP0Ree5Ttn2+bVhnh4Nn3Iwjr8+IFRURUPDY16 cgJg0PboswF7w== Date: Tue, 20 Jul 2021 13:54:38 +0300 From: Mike Rapoport To: "Matthew Wilcox (Oracle)" Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH v14 000/138] Memory folios Message-ID: References: <20210715033704.692967-1-willy@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210715033704.692967-1-willy@infradead.org> Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=oWbtO1C6; spf=pass (imf05.hostedemail.com: domain of rppt@kernel.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-Stat-Signature: 1umbyq6ra7hft4ohyzg9mwqky8m7zhb5 X-Rspamd-Queue-Id: 5132750135BA X-Rspamd-Server: rspam01 X-HE-Tag: 1626778485-361267 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: Hi Matthew, (Sorry for the late response, I could not find time earlier) On Thu, Jul 15, 2021 at 04:34:46AM +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. I like the idea of folio and that first patches I've reviewed look good. Most of the changelogs (at least at the first patches) mention reduction of the kernel size for your configuration on x86. I wonder, what happens if you build the kernel with "non-distro" configuration, e.g. defconfig or tiny.config? Also, what is the difference on !x86 builds? > Git: https://git.infradead.org/users/willy/pagecache.git/shortlog/refs/tags/folio_14 -- Sincerely yours, Mike.