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 4F0C1CD128A for ; Wed, 3 Apr 2024 21:01:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D4B716B0088; Wed, 3 Apr 2024 17:01:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CFB446B008A; Wed, 3 Apr 2024 17:01:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BC2916B008C; Wed, 3 Apr 2024 17:01:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 9F6066B0088 for ; Wed, 3 Apr 2024 17:01:09 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 2D323402E0 for ; Wed, 3 Apr 2024 21:01:09 +0000 (UTC) X-FDA: 81969440658.25.B0CDABD Received: from mail-ua1-f42.google.com (mail-ua1-f42.google.com [209.85.222.42]) by imf04.hostedemail.com (Postfix) with ESMTP id B30E04001E for ; Wed, 3 Apr 2024 21:01:05 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=QRyhRCpv; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf04.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.42 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=1712178065; 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=VBnYPakn94NYpkzI1Hg0VWyhoK6/Qh88vix5jZgmyhw=; b=vZ2FNT6CJLXVjsT0jSU7HdsgLA+fr5bVQU6zKk2FLRy+F1HEjfTXYGq1SMYnshUv98clMx N5+3Ow0f2D2YX807RrkSw2NL0OxtOgoY0ypp0+Qxi9Ckbd8SNFMOWok5d5fKohJ5ltdTgw xKsU0YlbMfxRlhHbnfK8Zgy9vEV4Yz0= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=QRyhRCpv; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf04.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.42 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712178065; a=rsa-sha256; cv=none; b=vkUtdrSF9/sZy/PTxjIfOMwF8sI+mHSy+kjJlSXg9j0YAOakBwMtv3sSQquxQ2rU8Rc5qA YO1Nq+o0AjZvkhxl8WFIsVC4Xie2tTN7qoeJsKVkfxaqnkUDtNtz2eGZCLtSydjhDpG+If yG5QpF1uGw0G7h0kcZQK9I60QA4/z8o= Received: by mail-ua1-f42.google.com with SMTP id a1e0cc1a2514c-7e3555015a8so102658241.3 for ; Wed, 03 Apr 2024 14:01:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712178064; x=1712782864; 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=VBnYPakn94NYpkzI1Hg0VWyhoK6/Qh88vix5jZgmyhw=; b=QRyhRCpvzb7+1lgLBeFr6dmyqYnirQOgxWW1s/PZwsPZiYQ/E8UM5v1OrvXwJGUkN8 ncx/H+r8gbgzK6SUoYMxdzWJsna9PznN4F5GV0qVFlsMvjWmuYiWH1rfBsaFxlbmD//u UhjeNRr6EeJS5gF5pSXgUMGPtP30lTvpXJJYSi2ZpibRhyTdiPRCHHqUnMbHQoJl65Zj +oMBBVO0QBVa9SPkfwQ9ox9i0ARELcNekdbF+CyDxphbs8p3iWnEanrS8SWTu4zkUO4S gtYyOX6greOIDPOLNnl7R6qZLsRsiqmrQuno53n7pHdg4Uiyg02TcgLEZ7kk85wQJU1+ ciFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712178064; x=1712782864; 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=VBnYPakn94NYpkzI1Hg0VWyhoK6/Qh88vix5jZgmyhw=; b=IDzZFrHgArBa7zy6O7F3ZNzJZMh+tElv/5Nzktd0zRe1by50KjfFENxIfCD2i7Mu1s Tv1sGaOc2z+B81vdrb1TQ2jyyI5VFDLqy85jV510UloZk2A9MCKkumNCFZtsq6nqTMSA z7hCqdHApGJD3+DP0zKRxSuNRPeMXKhmeSaQGkpWlkJGyE5tSWOMPZQ62wdQBUEhSkQX HD/JfFLW8aDp1FDnD5vBdMP0AeSsYwLTH9Llf7D2OZ7GH5nWxrI7JmsqYrvvNYEUE3Pk jHSilidqkuTLT2Aw1jFX7azjAmj3LgK0mXAUxKzz4BajWqr9ZANnTDAIzyirR0ZQY9Ee R39Q== X-Forwarded-Encrypted: i=1; AJvYcCVHM9Z7ahD//GzRKJKal96Sdyo11+eritAJz3sEpJY1Y7s+FRgMYhKwVMyVmlSVKl7at7e+jsb14i+mqgrVN9gd85A= X-Gm-Message-State: AOJu0YzlaZ8DLCmLoHSW8+9Kmr0celRtmhv7vUp/vBkFYFwOtLyHuuw4 Hqr6TWQneOKVJgZXY5wz55JAAxJGTeEjhmqP6QJT9NOtzM/HV3lBUEDbh/PCRPlzKy6fE689rTb 1xZKDqQYzhGVNQWAXdOd5eWEkIGU= X-Google-Smtp-Source: AGHT+IHztJVYC2ILeYUgiUtpoNZagKT64sKIeWbdNuExGyaj0OtApSBprogNKQbuwD4JiFSATvO3HUTg/65QfV3Tk5E= X-Received: by 2002:a05:6102:f12:b0:476:e7c9:83e7 with SMTP id v18-20020a0561020f1200b00476e7c983e7mr647148vss.19.1712178062721; Wed, 03 Apr 2024 14:01:02 -0700 (PDT) MIME-Version: 1.0 References: <20240403035502.71356-1-21cnbao@gmail.com> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Thu, 4 Apr 2024 10:00:51 +1300 Message-ID: Subject: Re: [PATCH v3] mm: add per-order mTHP alloc_success and alloc_fail counters To: Ryan Roberts Cc: David Hildenbrand , 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: B30E04001E X-Stat-Signature: t9yz1yctob414wkmxswa8sxra6b4918o X-HE-Tag: 1712178065-658550 X-HE-Meta: U2FsdGVkX19IJ7pkbHhb7VuLOwmPiXMneXBnieUSEtukV2QCSUg29NCx1+A701ndvOFBvpXbhtcqYRTrnPNsVALvPm2mLIAUie8H8jb4sJcs3U7ke3XbVkOqfi+m/Py8S8+mxB6OxMnhHzoA0cM1AzYAAYVvUNBtUVZd/YhdCck4py150SzIuaFslJZdfUrsnID3BA4o1glhwlKIQbYCz+lDn5k1UbKsm2X7mjox+eKJtWwoXv32r2Yp9vyDhFtNOWBmywzaf9V67/nCx0tczwsjvLk8IO4aa2mUVWKq0BkiZ1sBWyu8umkFRaLxgIIEVGqtrnc2eFCcqnGi0LECaqGCLGhFvIjgsE7OfRc1g+5AGddWp/qxLwfuM0D5l74zamlPtz+I+GnKzRhctSGY5I67jX4u4xtGZjjna4owRHYsYEWW2mfNCrLesNBTWZTgxtgfck3Tc/3bp0XGKO4TmtgjFL0dydRgwlXzh6AJCgtlQBfLMnRERHZRGJ5edK5sChW6ZGooqu4GOIWhoOs9g2CIKoLGUjJiOSy8tWo50PZxh3ROT2yJD9g7vA14wJjJzeKw2nFDdDcMDbqVpVgAqlVOZmXwaMzz/7VotiBwlT2oPWbe9ecKI0jxQY+7Fi+EiJDTv25qpJ+0clY2chxoWcaQKzvDaXaLpPw0AidiI8uEeN4tygxLduuIObHaTb1CRyqZUM8aS3sMlC5m4Loj2jyPmne3vJviU5UrOXxoo1QTSCNTzAxWtRBomwNnpBV3qXOhyIgsHNcBQRhwFDjn7e2iLBK0k6Eca6Y3S6wuN2SFiXfmGl4amaCqtJYRRdrDCYF5KC3eunykwTXVJErw1At2wgdv9xo/xHE7d7EUBfj8fIKRgRKvYkmbHb5ws2tvvLGvjbuIwWr8fI+0gauGDuh5dJZH910iuZ3AOuhMiQAAPigi8Q2yJCXBVSu0vHn8ye0V+x76imofHL3JCRk /pvBrF2Z Espg0xzbW0ba3jL5Lcoum7ml+R4KMGFZpkFwYES+lG7UlDDzDHvcPeLrLyU7WTpiRIKOU1CNSwoBBoLY/8Tr99SKvLWRKMc7Woq1NGkZf4vTdwEGAeQchYPKHLspfOppEto3kfO6dr6ttKzA6vdJLiy/Dcw0mRSAk3ZmfmKLA+dSHXxDO2hZ7wAnd2PHFJtig/cmMsMhUfl2SRdiMZuZViO8D9eJ/3GkAPDfpzGzedU86amb8OhlKPV3cNuZozVzE7khXHlTqDcnCF9JQ8ICxzi7eo/VIHSA/9HEKKFR5Zsj1Cuq4uzPBIh6+maItg4V0/xopdZCdARxiJg5qLaqcWbuviPJLAI7+E4NC1wfIjVtW4eWdaSGb2TSjh0Cgk2MEA6/GizB/E52JEkrgy1AVMuYiSWi+gSEzVatZ86FrPvO5B7ALn4vr5ldHxsVhJxbVZKaodvJjoKXuZtcMjV7Il1R8Wo+ZGYFljT+vShR+7pEKuazCPlUdnUAS0NirFfO4KmCrFHhHfyRQs0U= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000006, 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 Thu, Apr 4, 2024 at 12:48=E2=80=AFAM 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 "obvious= ly" > > 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 eve= r > 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 { THP_EVENT_ANON_ALLOC, THP_EVENT_ANON_ALLOC_FALLBACK, THP_EVENT_SWPOUT, THP_EVENT_SWPOUT_FALLBACK, ... THP_NR_ANON_PAGES, THP_NR_FILE_PAGES, ... __THP_STAT_COUNT, }; THP_EVENT can only increase; THP_NR_ANON/FILE_PAGES can increase or decrease. Thus, their names have no "EVENT". >