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 6F1C3CD128A for ; Wed, 3 Apr 2024 20:47:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E01BF6B0088; Wed, 3 Apr 2024 16:47:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DB1BA6B008A; Wed, 3 Apr 2024 16:47:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C52156B008C; Wed, 3 Apr 2024 16:47:25 -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 A3EDF6B0088 for ; Wed, 3 Apr 2024 16:47:25 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 19D3E1404FE for ; Wed, 3 Apr 2024 20:47:25 +0000 (UTC) X-FDA: 81969406050.27.34684E1 Received: from mail-vs1-f48.google.com (mail-vs1-f48.google.com [209.85.217.48]) by imf29.hostedemail.com (Postfix) with ESMTP id 43AF4120002 for ; Wed, 3 Apr 2024 20:47:22 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=WgY7nzEe; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf29.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.48 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=1712177242; 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=BKhe5eDbhQn9wto+cjdyLYyN+uaPFQihD+QuXq9Q3bA=; b=RiMLm1K2hZ61+uK1Xf5LHbOWlFZupjKAmsxXTJ29vloFHcrwdXzAisey8h0cJjall/LhOX 14Xj4ErQ3Jgk/WGejLq7Ucb/n+Fm6ogpvgx3gM9j0ObiG8O3cqOD23rkgKdHj3swVzgYUy apq3U6QyQUIxuNua3/9cw0eK47DrtB4= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=WgY7nzEe; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf29.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.48 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712177242; a=rsa-sha256; cv=none; b=wJ8PuMKuJ9+9dTu9WWCyl2+H8q2NDabXDOl0GuSrWTFCc2gP/q1WHPjajkebqipOFlYFKS JPceB4lq5GF1PLa3o8bY35CFO/TzV51hLtxl47A5QQjvGW5d0t56FSEOlsqMYcCjUOaosw yHSjzy/LFxXHQEShHfaXp109kUOiV3M= Received: by mail-vs1-f48.google.com with SMTP id ada2fe7eead31-4783964353dso109495137.2 for ; Wed, 03 Apr 2024 13:47:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712177241; x=1712782041; 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=BKhe5eDbhQn9wto+cjdyLYyN+uaPFQihD+QuXq9Q3bA=; b=WgY7nzEeNG958NmsaWhYLzB1Mgj8Um+Gzh5bWet7VLdATuwZT3Kqg+MPLVNC6btUNL N1exNjgYJx7AhjvTJm8gQjzMU4wIPPOJBtt1b6dImFv7iGY4CvNsIBWnIs2eI0OTT4+d z4n3iFqS/+W+7+VhRt/oYjO9bNmXp2FaknMTSaTb3CKjWzw8Qpa6V5vyGGxgcu8CVngs eUP5NqRn1HqIYyYnZOR1BADoiVJBrBTipbrRVGOI56wdTmYZ2vUJH2BJafsZNkX1Kgrm hEbfqcyiYvrpDPhDpyebz77qwoTfGaoEqd34A9vnaMyZyjvyzuGc1wvqv54+8Qcau36T zb7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712177241; x=1712782041; 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=BKhe5eDbhQn9wto+cjdyLYyN+uaPFQihD+QuXq9Q3bA=; b=qxStWxochLsxvCcB25cikz/R14WZEwZS1Hm87CHo7IljC109AlJjW0eZ7EswvvGfAk u88XJeeuRU7erZh29E853quBNVTxhgF/IJRcoREmPUuIlDJ/PVb1h0haJVKPw4e2FAb0 eE3CYoiJHvQd0eVOHBaeK5INX2WN+PCiS1A+FxlTsAOOpTUYRKewWELWU5MqcrqmUV1Z M5zkLqLNq+hsRoqG4e3miL8xDZS8rJhJqrlwypVo8ZpG7mJMiisTHqnmzKxNtezlf1Lb dfopUd95hx9liK/fPqK2hNv1GFsQdipsaPxCMbkctsSnpJTLINzUZwNyJhPjAzEhlXSs Jpdg== X-Forwarded-Encrypted: i=1; AJvYcCX0NEJVJs4y1tz1r8l2NZhjJlq+XrtO61sxbHPvEb4Xlh7NeW6IM/AbMmEwPhLa54UJS/b5lcAsWOiJeg2hACoSpuM= X-Gm-Message-State: AOJu0YzovnnbuAcvtNkXhSTwSza9BE58hYL4SvWqJwcrNUGZU/DgY+4X lxKQdyJolXRCjFw9MxDB8ha0WRAihixWXC9tJLcRbidoHigGqa7hxq5a7hCuAUQCXr2VwicNspz PuW/iR3ZEdBgkNxdq1a4cjMxKERg= X-Google-Smtp-Source: AGHT+IGuuGZ9zw3gfAi9SWE3ZrKYQFo7Rr5r9ChYzqQv1tywv1lQ+/jADIlBngAkM1nYWJM444/RcBnlVgUyZiSUr94= X-Received: by 2002:a67:f8d8:0:b0:478:2fe8:769e with SMTP id c24-20020a67f8d8000000b004782fe8769emr507450vsp.20.1712177239769; Wed, 03 Apr 2024 13:47:19 -0700 (PDT) MIME-Version: 1.0 References: <20240328095139.143374-1-21cnbao@gmail.com> <9c5f83f6-1e23-4c0e-85bf-454c1e3f07c7@redhat.com> In-Reply-To: <9c5f83f6-1e23-4c0e-85bf-454c1e3f07c7@redhat.com> From: Barry Song <21cnbao@gmail.com> Date: Thu, 4 Apr 2024 09:47:08 +1300 Message-ID: Subject: Re: [PATCH v2] mm: add per-order mTHP alloc_success and alloc_fail counters To: David Hildenbrand Cc: akpm@linux-foundation.org, linux-mm@kvack.org, willy@infradead.org, ryan.roberts@arm.com, 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-Queue-Id: 43AF4120002 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: bn6dcdxcbtagjaugakk84quii45oy3b3 X-HE-Tag: 1712177242-546410 X-HE-Meta: U2FsdGVkX19An49B3JnXrAvO+c240s9I5B0NsQ3n9+eAQN71OqEmocAFE4ttXivnsPE2NFkGnY94mR4z5dCCDsBxuG+exjB5MqSYd4V3JSOQC4qSSKB5bWGJ9X6CYmL7KKpaTrOjwf71y4QQOwUa6CcRtHMOxlBv+KOyChXHeI5MJgICAr8a4Pw4TZdS2Ym8lWMo3skOwOIUjZSiZ9JRGpSWI/DsN0IJl6vfEBKXKgm66NCEnl4feDe501vQ/7WjjCkO7zg2v8HpTwQm2Gb3lwTpypldq/haXMnHwHuCCKbgSwznBVkv96JO6EXh8eUiQBb8gDXjuBS7kSpavNXW7CxNCpn6m34cWWkn3JDKlqgH/MTo7GB264/ORrfNxxEepZpb53Qub0TdS77+hUa6Fq1VCcXkZg1yjfsXhvRWF7V4Qbn0iZ+jPpNb+QMExy+LhFIjn+FlO6GrphdA0EbHU87ilp8V5fDwsPfpVZMby5mxhA//t5gNAqkkkBicqYWAsyFcYoDpJNnAff8CYZdPKWBSBTaB03CXb+CcKEumpAhcX6HptGwvJUBzrb/+I9HuQLIT/4TxugEgluyW6YMrhWIlNg2TYtuMcRgglVPdwEeA8EpxqAGUAF3QV95EYW+w/vq2gqdQv9x9+IbZ+7pG+RpUjZH6ZZH40JP3yjZ3VPpktcVQa3jfYUzWJreXK8lwlIRn/UXXKCuHVFZ4fST8Bbz6bdBJ0ZyoD88Lds1tkBKjttdZGouATi2n+n0ANgIafGsNzz64k+PeG7hA+9iRb8wQitjRpiNUeDAs/pO7VYa6VIW5doXzJPL9HrpK+mqE7Rt+7k143ZfDYOdjmDwpgDaFWMpd77fJwwGQuOYaF0Lqky9D+wMRoP4u+IB3fpw4qGTPNZZ9sHoZ37VnZSr/jBZN14va/i2Bta09BDVETot2AtXHCBBvxmbp4RGvSmHw+mLMqSM5CjBQ+HtvVXs Ac1QYFrh BBVaYQJcdphsWaRO5v8uvKLMajP4mEYZiPNUTOeR8YsgOeT3lJjM3jPpOHcdJs0ROzDrJDvXLkwII/4X9D6zJG9agRTa9/WLe7P0VhQYD78ox8HdS4VplCJRUazD8icxnZODrzjX8hqrr0lCQOrQvluF8IIyMd7eOvMkWQA6GmRkVmTvAc7WI3cn7tyzpYpcZW1wRa6r0qRyfkGWe5T/yt60/HG4JnC7vZztKp1ZExnyGFbNUH7aEu/7Kof31v8CFbcCUXiDi7r9zIVEvi3jE9mUdZWY3JNao9FzBUpP72NDNiuJBypCuXRXBv12jzbK2w2fEvEMErHUiGUB9MO2E0S/YefeLWFKKzY/r2B+9a9UHA7shI1HOv3MrqMYiha9vHq7Nw7t0lEG68rT3EL54kh3lZ8C4388Kc6YJ0gWegKwp6p3cHgOXT+tXcJSItHY1sb4c9VX302KCoV85wf97NFT3uVO6JHNtSGuP5dzBrstYZ1ldU2r9fIpnUj8gu7MaCtIO0r/O3Ef1w43abOjlHF5X0HwAUHphhlgY1aqw/3AfT1puFLI568SxjKcsJ4nvaA6U 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:13=E2=80=AFPM David Hildenbrand = wrote: > > On 02.04.24 23: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, Willy > >>> -v1: > >>> https://lore.kernel.org/linux-mm/20240326030103.50678-1-21cnbao@gm= ail.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 > >>> +}; > > Why not simply "enum thp_event" ... "NR_THP_EVENT". ok. > > >> > >> 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_T= HP_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. > > Yes. Because anon was first, people just named it "THP". Then, file THP > were added later. Some of that needs a cleanup. agreed. > > > > > #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. > > Right. > > > > > I will rename it to ANON_THP_ALLOC in v3, let me know if you disagree := -) > > You should give people more time to respond before resending. Please try > sending new versions only after the discussion on the old version > finished. Otherwise it's going to be a mess (because I won't repost my > feedback to v3 :P ). agreed :-) > > THP_EVENT_ANON_ALLOC > > might be better, so "THP_EVENT" would be your common prefix for "enum > thp_event". > Should be ok. On the other hand, currently, there are numerous occurrences = of events or stats within mm, but we haven't incorporated "EVENT" or "STAT" into the naming conventions. > -- > Cheers, > > David / dhildenb > Thanks Barry