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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 15C28CD1284 for ; Fri, 5 Apr 2024 07:21:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6FB476B0110; Fri, 5 Apr 2024 03:21:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6AB6C6B0111; Fri, 5 Apr 2024 03:21:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 59A1D6B0112; Fri, 5 Apr 2024 03:21:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 3C2106B0110 for ; Fri, 5 Apr 2024 03:21:31 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 0873C410F6 for ; Fri, 5 Apr 2024 07:21:31 +0000 (UTC) X-FDA: 81974632782.11.8D166C6 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf06.hostedemail.com (Postfix) with ESMTP id 4C47D18000E for ; Fri, 5 Apr 2024 07:21:29 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf06.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1712301689; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=elF0k/K4a0I0qq4qe2S9c/2fNUvoy7mZ/+84UuKPw/w=; b=ybuxL6Tj0rxIpgV7g7VsyMSovNd57x6Ap30hebuPARowSWognW6X94IPirJ+hBCPRzQcmw TrOBoU+EhGteETwzcf5makbNSnkf6oBoCQMeHHSRhGDhs4Ms19mDSLy8TQPjN5CDQjAaZ2 t4oXgL2s0NP8FMUotacegOfiCwRGKAM= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf06.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712301689; a=rsa-sha256; cv=none; b=JCDtTpRCQxjTqeEF7xelllTr+GJyZ73F/6lKWEzPKT6YPlZ6xW7ssQVJtGPdEPVtkFwnac lz0nTHAsrhys09WtgBfgfI5cP7ANZk/mwULJVYtRITwbpRBX0E3CHhIhThUGLM5bdkFrQi lZ4PyM/KChGFPjdYSrR3S6I1BC7Ek44= 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 21E11FEC; Fri, 5 Apr 2024 00:21:59 -0700 (PDT) Received: from [10.57.74.169] (unknown [10.57.74.169]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id CFF6F3F64C; Fri, 5 Apr 2024 00:21:26 -0700 (PDT) Message-ID: Date: Fri, 5 Apr 2024 08:21:25 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3] mm: add per-order mTHP alloc_success and alloc_fail counters Content-Language: en-GB To: David Hildenbrand , Barry Song <21cnbao@gmail.com> Cc: akpm@linux-foundation.org, linux-mm@kvack.org, cerasuolodomenico@gmail.com, chrisl@kernel.org, kasong@tencent.com, peterx@redhat.com, surenb@google.com, v-songbaohua@oppo.com, willy@infradead.org, yosryahmed@google.com, yuzhao@google.com References: <20240403035502.71356-1-21cnbao@gmail.com> <30392471-71f9-4eb1-8855-d9c12499346f@redhat.com> From: Ryan Roberts In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4C47D18000E X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: i18a4yp15xf6gowu91ard7d4een8ph88 X-HE-Tag: 1712301689-861717 X-HE-Meta: U2FsdGVkX1/pv+9nP0Qo1ZXjGlPr5At9hnVc/NdfNgi6yLIfXFkOtgqOdc5mZJPgUszkyg0u3L5OXJ0LGtR8/lr54e3u3EDlyQx7I184Wh/EJVU8W17jeiPqXhn5icivQKy3iC1w1YYpDjnwt3l0ougHmAwPLGdA+QRQlygX2n5FZIxCYv870/YsA/ornNMIE2pqn6xIZUa5wheJqJTpYUQ36MM68jv9nW1fwsicgzLxsqR4ajj29J/JXjjx/TAdyMLq/PhZIek2mRwlFQvwbunAxqB+w9LlVnqxXU/Tagn3TEIl99dWHXeW6QuuWASWCbV25bE03u31T2C93xroM8ouQmZmvifgpb4Tr6WAf2P2vTQK83ZBk72GruW36ux0a5c1cebLmrA/OOaoss7IlTC6tM3plodyZvIfsihvoaG+zg+CMD25Fnqd6k6Loz8WKH6OK0HSwMCYKzNVY/XcjoGxQeiGqLkl1Ey6F23p9T3YxMWvkePoBI4AwOosYZPi19K2Fp2dAe8ETdBMoHzGjsXRS7kCBu/BBMhz/+rEcOT0aPfolr8Zc9fgkVLuWWNjmcdXGUywqzEhhN2z9S1sUERKBHxIyVx737GqGwQ13ngC0AiU4b+x4AZcmGGFrZCGet45l6cLDhIYroQ+oAiRpZMXZbi50HHAaGa5Yrtc06xp0AohFBT1iHGcIwEbUUmPJKWXUtJsl8GZ5x1sG/V0xA9jv4fM7u3L9qO+doaIPZgq0SP+RTRF7nYuZsWqIiiQml/GSn8zSlLxJXszIwEOFY/Of9T0PEDJoExATzqRIgGgGAe17pC7XIJp1Ht6aoHEI6ZtarrI/dTd39XnFtyrUyZ+W/jJwWNfqGOTIeNUbpAtuUbU4lFbiZSCuHf4cxbEzEGcNisFvIrosKMg70v4IHuN8mpopjw2EjGtKmaAtPvzax2WJhJvTlmmGcb6Z0e8cXa8whQ1lrif82Z8mhM I3e5lW5n lllo95zPFROireZ1VlU7SjZTgO1RotJnrA17Br6LTUJzC1nFu5MdtlXwLCGmsgnubX11oN7XHnFvhrOc99jd3mJS3uBoH+ByVn67fVzNPzp2SQRikYsBrGmv7eDpELbGt2iWkgJiC/7kTnFbmZEhlsqd+W1lqHt85rFoHS6YEHboemv9b6Q8PS2a1WQdeZj8vMViF66DGRTLb3qTmvpmxUBFYcWEUuW/g59hqlBN0Upw+CMEcbB5JMi+H2MOueiKKEdksKrPRQZcQnWT53by9JTVNVBhwpVFQKKPGJqZ9nAOVJAps19kADK0Tg0wlL0ywMN616XK9R+NaOyTaMI7mQ0xgAGkb7aI75+vPpT0NzlTDvaNnpfdgIUfVfOOY3Md11k/Q 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: List-Subscribe: List-Unsubscribe: On 05/04/2024 07:29, David Hildenbrand wrote: > On 05.04.24 06:01, Barry Song wrote: >> On Fri, Apr 5, 2024 at 3:57 PM Barry Song <21cnbao@gmail.com> wrote: >>> >>> On Fri, Apr 5, 2024 at 4:31 AM David Hildenbrand wrote: >>>> >>>> On 04.04.24 09:21, Ryan Roberts wrote: >>>>> On 03/04/2024 22:00, Barry Song wrote: >>>>>> On Thu, Apr 4, 2024 at 12:48 AM Ryan Roberts wrote: >>>>>>> >>>>>>> On 03/04/2024 09:22, David Hildenbrand wrote: >>>>>>>> On 03.04.24 05:55, Barry Song wrote: >>>>>>>>> From: Barry Song >>>>>>>>> >>>>>>>>> Profiling a system blindly with mTHP has become challenging due >>>>>>>>> to the lack of visibility into its operations. Presenting the >>>>>>>>> success rate of mTHP allocations appears to be pressing need. >>>>>>>>> >>>>>>>>> Recently, I've been experiencing significant difficulty debugging >>>>>>>>> performance improvements and regressions without these figures. >>>>>>>>> It's crucial for us to understand the true effectiveness of >>>>>>>>> mTHP in real-world scenarios, especially in systems with >>>>>>>>> fragmented memory. >>>>>>>>> >>>>>>>>> This patch sets up the framework for per-order mTHP counters, >>>>>>>>> starting with the introduction of anon_alloc_success and >>>>>>>>> anon_alloc_fail counters.  Incorporating additional counters >>>>>>>>> should now be straightforward as well. >>>>>>>>> >>>>>>>>> Signed-off-by: Barry Song >>>>>>>>> --- >>>>>>>>>     -v3: >>>>>>>>>     * save some memory as order-0 and order-1 can't be THP, Ryan; >>>>>>>>>     * rename to anon_alloc as right now we only support anon to address >>>>>>>>>       David's comment; >>>>>>>>>     * drop a redundant "else", Ryan >>>>>>>>> >>>>>>>>>     include/linux/huge_mm.h | 18 ++++++++++++++ >>>>>>>>>     mm/huge_memory.c        | 54 +++++++++++++++++++++++++++++++++++++++++ >>>>>>>>>     mm/memory.c             |  2 ++ >>>>>>>>>     3 files changed, 74 insertions(+) >>>>>>>>> >>>>>>>>> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h >>>>>>>>> index e896ca4760f6..5e9af6be9537 100644 >>>>>>>>> --- a/include/linux/huge_mm.h >>>>>>>>> +++ b/include/linux/huge_mm.h >>>>>>>>> @@ -70,6 +70,7 @@ extern struct kobj_attribute shmem_enabled_attr; >>>>>>>>>      * (which is a limitation of the THP implementation). >>>>>>>>>      */ >>>>>>>>>     #define THP_ORDERS_ALL_ANON    ((BIT(PMD_ORDER + 1) - 1) & ~(BIT(0) >>>>>>>>> | BIT(1))) >>>>>>>>> +#define THP_MIN_ORDER        2 >>>>>>>>>       /* >>>>>>>>>      * Mask of all large folio orders supported for file THP. >>>>>>>>> @@ -264,6 +265,23 @@ unsigned long thp_vma_allowable_orders(struct >>>>>>>>> vm_area_struct *vma, >>>>>>>>>                           enforce_sysfs, orders); >>>>>>>>>     } >>>>>>>>>     +enum thp_event_item { >>>>>>>>> +    THP_ANON_ALLOC_SUCCESS, >>>>>>>>> +    THP_ANON_ALLOC_FAIL, >>>>>>>>> +    NR_THP_EVENT_ITEMS >>>>>>>>> +}; >>>>>>>> >>>>>>>> Maybe use a prefix that resembles matches the enum name and is "obviously" >>>>>>>> different to the ones in vm_event_item.h, like >>>>>>>> >>>>>>>> enum thp_event { >>>>>>>>       THP_EVENT_ANON_ALLOC_SUCCESS, >>>>>>>>       THP_EVENT_ANON_ALLOC_FAIL, >>>>>>>>       __THP_EVENT_COUNT, >>>>>>>> }; >>>>>>> >>>>>>> FWIW, I'd personally replace "event" with "stat". For me "event" only ever >>>>>>> increments, but "stat" can increment and decrement. An event is a type of >>>>>>> stat. >>>>>>> >>>>>>> You are only adding events for now, but we have identified a need for >>>>>>> inc/dec >>>>>>> stats that will be added in future. >>>>>> >>>>>> What about the below? >>>>>> >>>>>> enum thp_stat { >>> >>> It seems we still need to use enum thp_stat_item rather than thp_stat. >>> This follows >>> enum zone_stat_item >>> enum numa_stat_item >>> enum node_stat_item > > > Right, we can do that. > > [...] > >>> ok. >> >> Hi David, Ryan, >> >> I've named everything as follows. Please let me know if you have any further >> suggestions before I send the updated version :-) >> >> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h >> index e896ca4760f6..cc13fa14aa32 100644 >> --- a/include/linux/huge_mm.h >> +++ b/include/linux/huge_mm.h >> @@ -264,6 +264,23 @@ unsigned long thp_vma_allowable_orders(struct >> vm_area_struct *vma, >>                                            enforce_sysfs, orders); >>   } >> >> +enum thp_stat_item { >> +       THP_STAT_ANON_ALLOC, >> +       THP_STAT_ANON_ALLOC_FALLBACK, >> +       __THP_STAT_COUNT >> +}; >> + > > > Final bikeshedding: so we want to call all of that MTHP_, mthp_ etc, to make it > clearer that this is per mTHP size? Perviously we concluded that mTHP was only for commit logs, and in the longer term we wanted THP to mean the full set of sizes like it does for hugetlb. Neither "mTHP" nor "multi-size THP" currently exist in the code base. Personally I'd vote for leaving it as THP.