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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 48536C00528 for ; Wed, 2 Aug 2023 09:05:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232654AbjHBJFG (ORCPT ); Wed, 2 Aug 2023 05:05:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58250 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229680AbjHBJFC (ORCPT ); Wed, 2 Aug 2023 05:05:02 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id F13742724 for ; Wed, 2 Aug 2023 02:05:00 -0700 (PDT) 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 C4271113E; Wed, 2 Aug 2023 02:05:43 -0700 (PDT) Received: from [10.57.77.90] (unknown [10.57.77.90]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2B1483F5A1; Wed, 2 Aug 2023 02:04:58 -0700 (PDT) Message-ID: <951a8d96-ecdf-7ca4-ec7a-e1c5eba8bce3@arm.com> Date: Wed, 2 Aug 2023 10:04:56 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [PATCH v4 2/5] mm: LARGE_ANON_FOLIO for improved performance From: Ryan Roberts To: Yu Zhao Cc: Andrew Morton , Matthew Wilcox , Yin Fengwei , David Hildenbrand , Catalin Marinas , Will Deacon , Anshuman Khandual , Yang Shi , "Huang, Ying" , Zi Yan , Luis Chamberlain , Itaru Kitayama , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org References: <20230726095146.2826796-1-ryan.roberts@arm.com> <20230726095146.2826796-3-ryan.roberts@arm.com> <8c0710e0-a75a-b315-dae1-dd93092e4bd6@arm.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/08/2023 09:02, Ryan Roberts wrote: ... >>> >>> I've captured run time and peak memory usage, and taken the mean. The stdev for >>> the peak memory usage is big-ish, but I'm confident this still captures the >>> central tendancy well: >>> >>> | MAX_ORDER_UNHINTED | real-time | kern-time | user-time | peak memory | >>> |:-------------------|------------:|------------:|------------:|:------------| >>> | 4k | 0.0% | 0.0% | 0.0% | 0.0% | >>> | 16k | -3.6% | -26.5% | -0.5% | -0.1% | >>> | 32k | -4.8% | -37.4% | -0.6% | -0.1% | >>> | 64k | -5.7% | -42.0% | -0.6% | -1.1% | >>> | 128k | -5.6% | -42.1% | -0.7% | 1.4% | >>> | 256k | -4.9% | -41.9% | -0.4% | 1.9% | >>> >>> 64K looks like the clear sweet spot to me. I'm sorry about this; I've concluded that these tests are flawed. While I'm correctly setting the MAX_ORDER_UNHINTED value in each case, this is run against a 4K base page kernel, which means that it's arch_wants_pte_order() return value is order-4. So for MAX_ORDER_UNHINTED = {64k, 128k, 256k}, the actual order used is order-4 (=64K): order = max(arch_wants_pte_order(), PAGE_ALLOC_COSTLY_ORDER); if (!hugepage_vma_check(vma, vma->vm_flags, false, true, true)) order = min(order, ANON_FOLIO_MAX_ORDER_UNHINTED); So while I think we can conclude that the performance improves from 4k -> 64k, and the peak memory is about the same, we can't conclude that 64k is definely where performance gains peak or that peak memory increases after this. The error bars on the memory consumption are fairly big. I'll rework the tests so that I'm actually measuring what I was intending to measure and repost in due course.