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 E9CAACD128A for ; Wed, 3 Apr 2024 11:48:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8277F6B008C; Wed, 3 Apr 2024 07:48:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7D7D16B0092; Wed, 3 Apr 2024 07:48:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6C60A6B0093; Wed, 3 Apr 2024 07:48:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 4E0996B008C for ; Wed, 3 Apr 2024 07:48:46 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id D560D160DF3 for ; Wed, 3 Apr 2024 11:48:45 +0000 (UTC) X-FDA: 81968048610.15.0CBE200 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf04.hostedemail.com (Postfix) with ESMTP id 18D4440004 for ; Wed, 3 Apr 2024 11:48:43 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf04.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=1712144924; 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=vtsDUm7Z5tU8dsK/UffQNrzO7SLjtbM345tIBazTnyI=; b=EbfIPZAEE2zDVEwjlNc5rc1jo5/xu7Pi7vTdREI8Z3nDQLznPWxgZMprm8ZuHJpC4Dr2hu vPv247d/TVvCPvY7dkD/AFM7AL0vi4S5p/sKqBqGz4KgVDGFB7G0UJOxgmqSn1bb2YEDz1 rMOC+CE7zAcJvVHZ10sHq2ZqRZyvJN8= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf04.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=1712144924; a=rsa-sha256; cv=none; b=vnwTztjxs6G9VuaMZcgdW4TeKEebrrhYIWiz0eIEdPRrtrNNhw6AvnSP0cmoUzQ8wYQdbd u7iaFq5bGk6U55SMYgAlCHXZGWxMSA3BiovTeV0WCdtHQOwo3Kw6ze/FQxSSdvwOKQiqFj AnGvMcV7zx68xnpO87W49Ujxwwphko4= 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 75C4A1007; Wed, 3 Apr 2024 04:49:14 -0700 (PDT) Received: from [10.57.72.245] (unknown [10.57.72.245]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 7E84F3F64C; Wed, 3 Apr 2024 04:48:41 -0700 (PDT) Message-ID: Date: Wed, 3 Apr 2024 12:48:39 +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>, akpm@linux-foundation.org, linux-mm@kvack.org Cc: 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> From: Ryan Roberts In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 18D4440004 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 198oow19a6r5i31z3fdkfqfnynkr6nyy X-HE-Tag: 1712144923-237676 X-HE-Meta: U2FsdGVkX18uTjnSK3GajcMo3CRtkxCavfyMQhJhCZtafNtuDwYO9aeRPQCUjx9pXhigxpooFxqHN8mw3oz16WCZLaH0zSR1GRqy9hXRj6f5b6T5YqV5L08jqGBVpFkWKJbp+cE3gsgmQdYWZKcLoSPihZb7qxyjDdU+Ji2212d08axMaxVB4WN8hcj3OfUXeJpOG0zMHRKLopegJVhgqYiSTXvefSHA6CTsUX2kytmgmHJ40kcxQwX/1GYzsHdIsr1YxEMuvuPcOK6hUWqnVUcFn137yJuMmnr/ZsB44O7sLHmPlvhicxwVPdsQdciH6JcZapqhDfkiy5qtbT2QBGWM1+Ofqx/eyWa7vvT+kb5cOjqQFux/FWg5ZYfwgxiWWJEQ1wunGDV2ZhT1/YIHhEtdcCODxUb4Y7jt404YAFI4SmegDv61kvtzomN5zus8BHeUmqJIk7NmYQzoE0ISC16t8koEySPbCwiqmOpgoRd83s2l54mKhZvipGutdYUY1MnlXqizE3xOeIKnTKAQ0uiuiXwuXIFpv8RNIWfuYUezOTk8U0k2F7jw3uaYMNV6aAny8bjfqosl71vBtgSBkNIY6OFIDIFfhSnv1FoPxm2Wwa/HawBoEuBYKCOf4kZruS/Hb0nMg8VUq4HWud+r/HSVGdqg+dkeMGcnjbkvhlpCeXZhxlYNv8rxl7iLFvLL5jjjGkmVdZjXfCWz72A+877UyIl5cTeHOtktI6cdIn7x59M/+pLvOK/XbSmMUl5j9pko3d8yJOnQnRp6SFxqrZSe06RXpaoPPXO2Rw4C7QBIFtO+MjyFeHdzgNPKUg1Q3qolDeyfWYI+wf6BnYP3/Ub2CK7NwUmsmY6iM/Jomec2sSo1H5JsSt9Bjnx3/6mxmYomx5+Clkp8W8SFkXjcVS7mRKl8wy/PHEhk8C1CV02/QrPwCOXFYsMixTrdHI9Z8ZGrT7YNMbsdhCaW2IH YV8B9kDT 5v+g/QyMLXqX/NXuQlbJDRLLMjDBuIH1TFzo1OJpneE11MtuJgjj2epI77N+PdA+HYA9+Jko27/Cbacz9iTZ2zTom7qvN3AT85lx5dKRViMJfr8SnL5hAnFerKe0+QlV5rJ/pKlDgQpVGWbq1LDpfnOFDDYIKszP7N12DqoR9glnai8Qn2Zi0YDbY0jvsKGMhkZSwokmZGDK3JB6FKJuyEYJoKuhqilaxU5zxzzRk9I1RQZdz+B/3nK5CFiG3RbQCJkza/xRcNASvmvLV6he3PUKuwQ== 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 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.