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 EEDD5CD1288 for ; Wed, 3 Apr 2024 08:18:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 850496B008C; Wed, 3 Apr 2024 04:18:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8008A6B0092; Wed, 3 Apr 2024 04:18:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6F00A6B0093; Wed, 3 Apr 2024 04:18:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 50E5B6B008C for ; Wed, 3 Apr 2024 04:18:13 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id EE0511A0DAA for ; Wed, 3 Apr 2024 08:18:12 +0000 (UTC) X-FDA: 81967518024.26.E6E9724 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf21.hostedemail.com (Postfix) with ESMTP id C78751C000A for ; Wed, 3 Apr 2024 08:18:10 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf21.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=1712132291; 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=n7husBVnrIRWpgbyx8bRvkplt2lonhrPxmcmtZdkIu0=; b=NcoZWi48O1p7nYyKHJL0Xq4M8Z0d+JSIIs+5Y38gy7WXyIbrlpRP5L5y47GDF89WUs46Yl pn5udgrdeMiEzEUepylL0UHBfehwnjA4T48o0GD/+XS28glothieimzYcron4FXDPQMM/G CdKffI49uDIwUGjcXCeOU2dhbRAoopg= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf21.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=1712132291; a=rsa-sha256; cv=none; b=Q9ToK2J1RxdrnWoVcWQwKqsexQSeBt1AqlhmNSqmUYvNFoW70COmpJxxpQ9VaKHCo92nA+ f+PRV5O5lLsxT/TWGdLVCVymaLKm/fI3qs5bY2PWIw0WZc4IXtEpL2g36rSnaWkeh19phN /sZBhvLarfnph1OucLwkVYZChePN+tw= 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 25B421007; Wed, 3 Apr 2024 01:18:41 -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 179A63F7B4; Wed, 3 Apr 2024 01:18:07 -0700 (PDT) Message-ID: Date: Wed, 3 Apr 2024 09:18:06 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] mm: add per-order mTHP alloc_success and alloc_fail counters Content-Language: en-GB To: Barry Song <21cnbao@gmail.com>, David Hildenbrand Cc: akpm@linux-foundation.org, linux-mm@kvack.org, willy@infradead.org, cerasuolodomenico@gmail.com, kasong@tencent.com, surenb@google.com, v-songbaohua@oppo.com, yosryahmed@google.com, yuzhao@google.com, chrisl@kernel.org, peterx@redhat.com References: <20240328095139.143374-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: C78751C000A X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: chzo4xw5wz563ejr8aq4jooujym9psds X-HE-Tag: 1712132290-977441 X-HE-Meta: U2FsdGVkX1/4j0SiSgsaHd76eOuWf7C2SZy3Jujx0Qd+AV3nNuuybkTK9CrD8oMAXBB5QRBw9bRBtGW2W59nmpCWqdmsOnlk4ggjxrckDZSUq1J6LXY5kuJNuaPJZi+NAH1DzPteMICJU32HprxqlAX8vWhzNspQDRgwYU1jpHeiK+Q2ruAIClw8ER0SVjseME05zpSlW1uFvJ9bSJuSmFoppIww3sdjH3iq16qIxXxNXyHpBnO7fh1eR8Zr5AhR/a7dNF0IgkiJeQJYqMogZeT2CaZhhQt8qc/smCXS/Pq7l9i3mchKy5BP03R7wGWYe2ouyKapO23Y4TtK99onnK0hUXI1oDLrxgbVLkHYJ0sZCyZeyNq3RtKASsOnh1JTJvojIqXIshkvBRAu+OViB+E4HIxnX+va0BpKu/S/M2JTMFHTPqEgt6USkr1fwJwGcusCUEDdKEQaSolNAWOJmWpmDOg+aGPKuH+fxtNwW7tHesauDNUH2LnIkNd3wqqeBplCR5sgNox+S3JpNUX7WWlhXF33+THYaaWpF3dP1Wd2OvejSLCYFzhmk047GnUo+/NRYPvTOleEsN40Ph4R6yazqq08O3XgY/wRdl2G9rYcKKGIDWVrVhGGUQoUt12HNa2IHocfQKuRmMi+llu1gAnDtSVPM7nBRiWneohGcEmtHgYEHN5CezPhEpMOqhP33PN05jBncodyXGm6rOxWZ1pNKPZ09lQiEm0728rdHM0I8UQATWbhYAGvHhsEeTCSgrlm+NowuWLk222/rAAsoN6zAlPLr/+7AMQuougQd5rxGMnBV8l967mYatr24kPbcqinMXp89iZ/cKpKa3spryQ5kmKAbjhbbEM0Ywzh8kq8jr41Lnsm9Y0GFTvHzzgzvX6itwAC2X+B5/FlIzokpIj6ba6n766G6ALtOqD0IBHUqyfmKpdWRDCfjR+GvlL40LIQ597dxC6/jFn568F VXKgQU1K E9kHS/KBYiFU3F5vZcte1G+Q+NsdABHYcVXxJSRuOka4JbOpySCLfEDMb0azJsSvWkX7c3Z+zmyIKSnTChQtCIAI3naKMDc6hDfJOSgvPC9SqYLxh9t64tJOAWGEdjdDEfXVBme9PnBiAGGMy0TbsEGaTsD4EZ0TJtEH1E8PlcW0w7BfqHXO9qyUlBk+bGnWfGFexANSOJiLuc8P2gFFF6qO3KVHyqUS3UtUMQiwd+pKoQoZMf9hagXTFt/HL3fDpy9yc9xqZVjwAtaVOPMBlbGXfpbgtmCo0N6NQJhGPLHd3qtsVOYM7oRbqFHiJ742lOssFzgsK0rwKdKkYU9MKPgyBql3o3+jXlqXSmdCdLnnW67k= 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 02/04/2024 22:29, Barry Song wrote: > On Wed, Apr 3, 2024 at 7:46 AM David Hildenbrand wrote: >> >> On 28.03.24 10:51, 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 alloc_success and alloc_fail >>> counters. Incorporating additional counters should now be >>> straightforward as well. >>> >>> The initial two unsigned longs for each event are unused, given >>> that order-0 and order-1 are not mTHP. Nonetheless, this refinement >>> improves code clarity. >>> >>> Signed-off-by: Barry Song >>> --- >>> -v2: >>> * move to sysfs and provide per-order counters; David, Ryan, Willy >>> -v1: >>> https://lore.kernel.org/linux-mm/20240326030103.50678-1-21cnbao@gmail.com/ >>> >>> include/linux/huge_mm.h | 17 +++++++++++++ >>> mm/huge_memory.c | 54 +++++++++++++++++++++++++++++++++++++++++ >>> mm/memory.c | 3 +++ >>> 3 files changed, 74 insertions(+) >>> >>> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h >>> index e896ca4760f6..27fa26a22a8f 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_event_item { >>> + THP_ALLOC_SUCCESS, >>> + THP_ALLOC_FAIL, >>> + NR_THP_EVENT_ITEMS >>> +}; >> >> I'm wondering if these should be ANON specific for now. We might want to >> add others (shmem, file) in the future. > > I've two ways to do that > 1. rename to ANON_THP_ALLOC, so that I can have SHMEM_THP_ALLOC, FILE_THP_ALLOC > in the future; > 2. let THP_ALLOC cover all of shmem, file and anon. > > following vmstat, actually 1 might be better as we have both THP_FAULT_ALLOC and > THP_FILE_ALLOC for pmd-mapped THP. > > #ifdef CONFIG_TRANSPARENT_HUGEPAGE > THP_FAULT_ALLOC, > THP_FAULT_FALLBACK, > THP_FAULT_FALLBACK_CHARGE, > THP_COLLAPSE_ALLOC, > THP_COLLAPSE_ALLOC_FAILED, > THP_FILE_ALLOC, > THP_FILE_FALLBACK, > THP_FILE_FALLBACK_CHARGE, > THP_FILE_MAPPED, > THP_SPLIT_PAGE, > THP_SPLIT_PAGE_FAILED, > THP_DEFERRED_SPLIT_PAGE, > THP_SPLIT_PMD, > THP_SCAN_EXCEED_NONE_PTE, > THP_SCAN_EXCEED_SWAP_PTE, > THP_SCAN_EXCEED_SHARED_PTE, > #ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD > THP_SPLIT_PUD, > #endif > THP_ZERO_PAGE_ALLOC, > THP_ZERO_PAGE_ALLOC_FAILED, > THP_SWPOUT, > THP_SWPOUT_FALLBACK, > #endif > > And reading mm/shmem.c, obviously, shmem is using THP_FILE_ALLOC. > > I will rename it to ANON_THP_ALLOC in v3, let me know if you disagree :-) I don't think the name of the enum is important - its an implementation detail that can be changed. Its the name of the sysfs file that matters. Although of course its nice to keep them in sync from a maintenance pov. Currently they are called "alloc_success" and "alloc_fail" I believe? Perhaps "anon_alloc" and "anon_alloc_fallback" are a bit more in keeping with vmstat? I'm assuming that: vmstat:thp_fault_alloc == hugepages-2048kB/stats/anon_alloc vmstat:thp_fault_alloc_fallback == hugepages-2048kB/stats/anon_alloc_fallback ? Thanks, Ryan > >> >> -- >> Cheers, >> >> David / dhildenb >> > > Thanks > Barry