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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C2249C77B6E for ; Fri, 14 Apr 2023 16:19:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=4IByotAU6Fk/CliRm5Ihp7IvxpblzHdXHft1nvjW/gU=; b=xkDdekq12klpYs 9H8+0PHwQlNLUG7Dfd5WUhkS9e4r27eZ1/2JR2lEAudQNw/IlaTEWzl0HLOOBCPFQdohfSDDMjORM A8RDF/TRAC+fmw9XocGUvWIgmplzjvtmUF9mEwuM89ei91rOHuFFFIZvcRPMd8eT711cwVXh69rVM UryXcoyqti0gTs6BedBQSg/KO9v7pY1Nc1TfACjdDr1OHUjlVpva/6SsFnI4Y1O8IlbQ8lEMEpv7u QxE2xals9zwSNUbKU0u9c7b8HcPtLXhTyXqicELI17hs0VlnYQDuYg/JJiG7rOm1mfRoBP0vcPzhK IxYEFLnban7cImCczYBA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pnM86-00A5Tx-2u; Fri, 14 Apr 2023 16:18:30 +0000 Received: from casper.infradead.org ([2001:8b0:10b:1236::1]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1pnM85-00A5Td-1T for linux-arm-kernel@bombadil.infradead.org; Fri, 14 Apr 2023 16:18:29 +0000 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=cS5oE4dq4L/8Z8t22e00OPv5vVVPGtUAiz+LjEIScJM=; b=L/oBdelFwWGqRqIciG5bBJU2bk BuILNnTz3tnV7lWCt3PddrtFl2OWXo9on31dgmcv05KlbqMMhr1OCQRDFH1bKicogmWZ7/56p2AVU 0kU2BINDMtQNYuEgM50x2iDIDXHEMjsvWpEh2DeTAWuZceJUdm2R2iVRV0Xj8nT38NFKH2oRnBi7G ZBlNQJ4k2ZXtMHrVlMsU+TtzyiOujQ8WSWyDYo06GkIeUOdxh3QJb3PpfgRK3OCaMhQfOfJrRolPU qM0oVo+k9d9lM50OOdcKU3/Pf6icuKm9tSDQi8JklrABYAp4Gwkg27me76tQG/7Af5HBV+X1rYWFJ sl1sOLuA==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1pnM82-008t4M-Eu; Fri, 14 Apr 2023 16:18:26 +0000 Date: Fri, 14 Apr 2023 17:18:26 +0100 From: Matthew Wilcox To: Ryan Roberts Cc: "Kirill A. Shutemov" , Andrew Morton , Yu Zhao , "Yin, Fengwei" , linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org Subject: Re: [RFC v2 PATCH 05/17] mm: Routines to determine max anon folio allocation order Message-ID: References: <20230414130303.2345383-1-ryan.roberts@arm.com> <20230414130303.2345383-6-ryan.roberts@arm.com> <20230414140948.7pcaz6niyr2tpa7s@box.shutemov.name> <2b76ee7e-06d1-94ca-d22e-46b6302b7c30@arm.com> <20230414153747.n5kyhvb5a726lvrz@box.shutemov.name> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Apr 14, 2023 at 05:06:49PM +0100, Ryan Roberts wrote: > The point I'm thinking about is for 4K pages, we need to allocate 64K blocks to > use the contig bit. Roughly I guess that means going from average of 2K wastage > per anon VMA to 32K. Perhaps you can get away with that for a decent perf uplift. > > But for 64K pages, we need to allocate 2M blocks to use the contig bit. So that > takes average wastage from 32K to 1M. That feels a bit harder to justify. > Perhaps here, we should make a decision based on MADV_HUGEPAGE? > > So perhaps we actually want 2 values: one for if MADV_HUGEPAGE is not set on the > VMA, and one if it is? (with 64K pages I'm guessing there are many cases where > we won't PMD-map THPs - its 512MB). I'm kind of hoping that all this work takes away the benefit from CONFIG_PAGE_SIZE_64K, and we can just use 4k pages everywhere. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel