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 17709C77B72 for ; Fri, 14 Apr 2023 14:39:31 +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:From:References:Cc:To: Subject:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=7mXjPYorEx9htKTGvczwGhKFSctlGODfJm7LVuqURKE=; b=RZh5fwRsG3Zxhm prWB5FBpNZR6GgKYIgVAOwZaiylx9vqyM5vHb/ibru3ynbYiBm71FoST7fljBM2pN1+9yJ/VLynAp roeQO7kgG0ghyKeGdXCeWsuEVWtoirmtSiOS6hlUuFnO8VdsCN6qsriTZXqmWvldbCeb2r42X2Pq+ SekDW23aqSnqVoqWnlpNrX+UfzxPTn+nlnV1Ncx3eQ8cLr1/2STmYAxub9CHtz7yLdMr1KCvAyYks 07dYQM0Su5Mc4O0c/6Z4WMvCIoqhMhhniyVMSoEpJ0pCt1p8SVKzEf7az8/DA12+gqOSWRdtKVrAE CeXvlA/BErz7tBm/TWxw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pnKZW-009qPj-18; Fri, 14 Apr 2023 14:38:42 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pnKZT-009qP0-03 for linux-arm-kernel@lists.infradead.org; Fri, 14 Apr 2023 14:38:40 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 7BE572F4; Fri, 14 Apr 2023 07:39:22 -0700 (PDT) Received: from [10.57.68.227] (unknown [10.57.68.227]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id EE1433F6C4; Fri, 14 Apr 2023 07:38:36 -0700 (PDT) Message-ID: <2b76ee7e-06d1-94ca-d22e-46b6302b7c30@arm.com> Date: Fri, 14 Apr 2023 15:38:35 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.9.1 Subject: Re: [RFC v2 PATCH 05/17] mm: Routines to determine max anon folio allocation order Content-Language: en-US To: "Kirill A. Shutemov" Cc: Andrew Morton , "Matthew Wilcox (Oracle)" , Yu Zhao , "Yin, Fengwei" , linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org References: <20230414130303.2345383-1-ryan.roberts@arm.com> <20230414130303.2345383-6-ryan.roberts@arm.com> <20230414140948.7pcaz6niyr2tpa7s@box.shutemov.name> From: Ryan Roberts In-Reply-To: <20230414140948.7pcaz6niyr2tpa7s@box.shutemov.name> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230414_073839_232205_264B4D75 X-CRM114-Status: GOOD ( 16.20 ) 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 14/04/2023 15:09, Kirill A. Shutemov wrote: > On Fri, Apr 14, 2023 at 02:02:51PM +0100, Ryan Roberts wrote: >> For variable-order anonymous folios, we want to tune the order that we >> prefer to allocate based on the vma. Add the routines to manage that >> heuristic. >> >> TODO: Currently we always use the global maximum. Add per-vma logic! >> >> Signed-off-by: Ryan Roberts >> --- >> include/linux/mm.h | 5 +++++ >> mm/memory.c | 8 ++++++++ >> 2 files changed, 13 insertions(+) >> >> diff --git a/include/linux/mm.h b/include/linux/mm.h >> index cdb8c6031d0f..cc8d0b239116 100644 >> --- a/include/linux/mm.h >> +++ b/include/linux/mm.h >> @@ -3674,4 +3674,9 @@ madvise_set_anon_name(struct mm_struct *mm, unsigned long start, >> } >> #endif >> >> +/* >> + * TODO: Should this be set per-architecture? >> + */ >> +#define ANON_FOLIO_ORDER_MAX 4 >> + > > I think it has to be derived from size in bytes, not directly specifies > page order. For 4K pages, order 4 is 64k and for 64k pages it is 1M. > Yes I see where you are coming from. What's your feel for what a sensible upper bound in bytes is? My difficulty is that I would like to be able to use this allocation mechanism to enable using the "contiguous bit" on arm64; that's a set of contiguous PTEs that are mapped to physically contiguous memory, and the HW can use that hint to coalesce the TLB entries. For 4KB pages, the contig size is 64KB (order-4), so that works nicely. But for 16KB and 64KB pages, its 2MB (order-7 and order-5 respectively). Do you think allocating 2MB pages here is going to lead to too much memory wastage? _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel