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 5E4A5CD1288 for ; Wed, 3 Apr 2024 21:06:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A1CE16B0087; Wed, 3 Apr 2024 17:06:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9A5066B008A; Wed, 3 Apr 2024 17:06:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 81FAC6B008C; Wed, 3 Apr 2024 17:06:49 -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 57EE46B0087 for ; Wed, 3 Apr 2024 17:06:49 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 14EAC140C0E for ; Wed, 3 Apr 2024 21:06:49 +0000 (UTC) X-FDA: 81969454938.10.B581FAC Received: from mail-vk1-f169.google.com (mail-vk1-f169.google.com [209.85.221.169]) by imf09.hostedemail.com (Postfix) with ESMTP id 4617F140012 for ; Wed, 3 Apr 2024 21:06:47 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=kErkazhs; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf09.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.169 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1712178407; 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:dkim-signature; bh=os/2b3ZcY1Q550Dopf3cuYF9Q9FW93sSTIW8haaLyFo=; b=Sh6Yzzjp6c7H7jWQV/zgs9K7OLR8cy5BYGHSLGbd5vT09+znZjjlQMu/OalgYLMcairLZ/ mRur+LXEruWhA99aUkVafSI4aBlc7xuNZUzGGZyAF+/4foxTwHLIgyxYqqOeHd8jg+PR4J 46TXu5a+jZxRKrAlstAgOCc7/WdQW/I= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=kErkazhs; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf09.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.169 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712178407; a=rsa-sha256; cv=none; b=G+1+pikMJFVvHmaBbH3AsvnKCgIiphEhGXEcSxgCMB0qkvr8BOQ5UPFeIGkJdhMOTkKIwr LNbrTqtonSr0KeeH5KCUJYRgQoIJnHn0UMiSn18zmYShjIjSYuFzIgnOBsBeWqOQ2+dUXZ 75LAsdgbe1kf3MsfvxGsWW4GTBPq6I4= Received: by mail-vk1-f169.google.com with SMTP id 71dfb90a1353d-4d8804a553dso113998e0c.1 for ; Wed, 03 Apr 2024 14:06:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712178406; x=1712783206; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=os/2b3ZcY1Q550Dopf3cuYF9Q9FW93sSTIW8haaLyFo=; b=kErkazhsv/axtk1FUw8HHhfybN4Tt3n+l0Ot8UFXDw7hZxH9qJOc4N1jl72IwyMxx0 cBKAv8Qb74qNRnEblHoREaHP+5pLiIsNQZYfIXNlKGx6RfT5/RlgPVMbxWPZJF0kQ1JU GYFZywGXEegMBFyYYE6Ep11tFW5akaF/PNDuqiqznnwffTff+tDtqDiVL2eay/qINv5y 2EZyOx1qdmuVccr72u1MFGDYnu1pxo90oqJ5kPDd4P2xaq4OjRlVmJYUXYj+BkIjCuwM 1ZiE9lh0o5BMhs/5VGqic40WO31racut9VKRx7YlQE+q20PJo99iXg+YPteu2nhaRm71 VE+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712178406; x=1712783206; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=os/2b3ZcY1Q550Dopf3cuYF9Q9FW93sSTIW8haaLyFo=; b=bCwVcsDzmzIpdi6jV8tnlcSwkVfG3u7/BdLs2mm9pN6SL/9dh26vzggiIA6W1r7C2+ uwVuDllwYqjcwvu4yH5vDq0X2zemecK/YccP75DwafeSTeOZKDSGyv8o+DWqMdLBXVDC XIVJQeg/CKECkQZil3hxJR/S8cF51yq+3SxZW02sAIcIFu3V165wdA1ELfgOQHKKoCmg pc57I2ei7sgx/2RbKH6jkdVtjM/3Yn3FEEhFERvPY8W9Wr65YIneZ1ZNxxVvcaXw/Ibe CZ4ABOwoaHZZeM+swAljJ+lCl9ZbPbmZUj2hNqHwKIo1zVm8w2LdEIPXpPLlchZ2KAh8 rzww== X-Forwarded-Encrypted: i=1; AJvYcCUascIzkMdWKEv21nbkkDyhpRNTj+G+5BLIr1VoapvMYtcrEdbC/4IOjVBZr/6flQfPchtbCkGUSxZ1NOpUrvoluTM= X-Gm-Message-State: AOJu0Ywhd9D7iYudgKacRiJLWRKRZvMOHtUHla45r0AE9RjRaE+zLQ+4 22YK4pvAc2WdXuXemdpAx7mXd6Kk32epou17IoC8xg6xnCl9u+XPRUh6cjzTWHdOJBfx5ic/rSw z6zJZAwO5cawzAtNTTbHXnbMwogc= X-Google-Smtp-Source: AGHT+IGlQ/JMk1pPL23dNjMkig5EQGrbB1ua+46b3+km4A2pUcD4JrXuvYqiPQY604C45mgnixAeSpjd4IpzV8jZUvc= X-Received: by 2002:a05:6122:4c02:b0:4d3:45a2:ae4f with SMTP id ff2-20020a0561224c0200b004d345a2ae4fmr436280vkb.14.1712178406276; Wed, 03 Apr 2024 14:06:46 -0700 (PDT) MIME-Version: 1.0 References: <20240328095139.143374-1-21cnbao@gmail.com> <56027891-090b-4501-ae0c-a86077caf303@redhat.com> In-Reply-To: <56027891-090b-4501-ae0c-a86077caf303@redhat.com> From: Barry Song <21cnbao@gmail.com> Date: Thu, 4 Apr 2024 10:06:35 +1300 Message-ID: Subject: Re: [PATCH v2] mm: add per-order mTHP alloc_success and alloc_fail counters To: David Hildenbrand Cc: Ryan Roberts , 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 4617F140012 X-Stat-Signature: gpbebf3ib8exegwtfacjzkg3yui4u4xm X-Rspam-User: X-HE-Tag: 1712178407-389536 X-HE-Meta: U2FsdGVkX1+/deTViTNZ4d4BbbMVuaS/Q8zZ3/izQ9SG5DkNrmUVAhjpLp0S9l5Ro+2KqlSiNR5wkN0YbdaJ33M7fE5KrltefCR8FjF4MIi/HUCf8Rt6o5Xjg8RzONZ86zZ7/dOLja8QOUSnE9jvRPi0DU2oK56apEGkpo4Vg/Y1kMUpclF2jNnA4gNLveHoJdVUXK1MIDn0prDjFfhcCpSYE8kkR3k+WxaUkjSenz04kQSIiO25FQTLzBXzXJeooC0DvvYRPcIizUqWIfI9dc3V7vnP/HJZAiZTqSRkw2HJ5H+rsMzRTQXayajEB/oLRBSxbC94z8cBlstbaJ5XtLdHyX0vnzjZdzrqXU4ay/+L/9OelGjxAmz+J9eIjmhyngvAHkNNjUy0EJcMIVt8kQa6wHo+XJZDOG9hl91v2eEHpjuQT2+u7gzktaez8YNehJFe6wa6H+mnyTxN2rO15nuh2mGU7esfoQrN9a4xNkTLtTVnZsWHC+P6OXluMA9y5zYUna86qoVfujfJ8krjvvegaH6MgRlcxekafoGl19fXjXP3NIssh7wIJj9MW6JW9M/S74t2uDVKpLXj4TvgykB0r1YNjP7CV/Sf3WqM4h+6chDTfrrE4dcUSZyoqLqZCdpuSyxLUcfvO4rm2VGvWYjyu3ZsNIhmoVFaiezPL3u97DsxZojK9cJgbKrmvNvCd/Mc88hlFNH6Poe+MPErJJhoKLoAfuFV528nJv92UE0NR2xWRrAJ/U+iZ3rq7UTPOlCdtwv1uLzplte9rALUQ0wOMgwCkDpcbxMgErzZ47IKPGu+kSz8XWWVP52Uj/3g1XQAfbKh59Qic4B2H/Tv85SJ3lxgtpM4NwhGMgAj1aV22WAw/CYWPi8qK+4JVCG2NvqNr8h+Nvs4/7DNHl+RGVYdQqYFOvJWSKD1gCbkN/bjyLA3rayVbhYylVHrEz22XuC3Ao0wv8qH/at0A5p x8elx5f1 NjBVJLEY8RcAoN/LI0DFvKWMFQ/ZF2VoPG5zYBVUCyizG2URrj5ipuKZQA7a1VerMGXE53IBRh6TE5h9OUBGWSOMBuEz9xwGyZr8RDJ9kgj3nHCgqz5/xQ0tDFDYin+WPa5pNCUIpmCYbv4Ci4O9P1uKeZiGBCczyszaztMIsXhOhbwuMu6lA+4rAstrpKJJc7Qw62/6+XdBr6zuSG015yVSoKoLEHsvTjz0XAcf/8NC5IJ/JcqbXxgTpEyKJ6I6Buy1SdrgvoY3F5YNS5KBNQaZkgxO1BFFCsNWnUsgaK26ORCF7gycqHhnSLFd3V8bziBcr1hsVIpkhZYfmolLDNL8WMVD/fW1xWnMvaWcWlc5G+S0QWblGiJ8mi2+aLk5QgDGDDIu0c5awar36ceR4i2uXe83HYVDWYy06u5dsqvkvapgdQAgzC7D+gG0jrXCkr0HHj1YPzfr0ppUSaNGfgkNKmbCmvOnQVqvS5yZZSmzke8OFPkB71VzJqHBfUrc1v6YqUKRgLSgO9KxwZFqtoJqq0A/X6QNijGvqOFb8LljT0Y1zG/BFKmur/0q/ErPlfqEi 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 Wed, Apr 3, 2024 at 9:24=E2=80=AFPM David Hildenbrand = wrote: > > On 03.04.24 10:18, Ryan Roberts wrote: > > On 02/04/2024 22:29, Barry Song wrote: > >> On Wed, Apr 3, 2024 at 7:46=E2=80=AFAM 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, Will= y > >>>> -v1: > >>>> https://lore.kernel.org/linux-mm/20240326030103.50678-1-21cnbao@g= mail.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 v= m_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. Altho= ugh of > > course its nice to keep them in sync from a maintenance pov. > > Jup. > > > > > Currently they are called "alloc_success" and "alloc_fail" I believe? P= erhaps > > "anon_alloc" and "anon_alloc_fallback" are a bit more in keeping with v= mstat? > > > > I'm assuming that: > > > > vmstat:thp_fault_alloc =3D=3D hugepages-2048kB/stats/anon_alloc > > vmstat:thp_fault_alloc_fallback =3D=3D hugepages-2048kB/stats/anon_allo= c_fallback > > Or an "anon" subdirectory ... not sure, just a thought. I'd rather streamline the directory structure and incorporate "anon" or "file" details into the filenames to avoid the inconvenience of typing lengthy paths. we already have the "stats" directory. > > -- > Cheers, > > David / dhildenb >