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 0FDE0CA0ED3 for ; Tue, 3 Sep 2024 01:53:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 956E96B03E6; Mon, 2 Sep 2024 21:53:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 906CE6B03E7; Mon, 2 Sep 2024 21:53:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7A7E76B03E8; Mon, 2 Sep 2024 21:53:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 5D1D46B03E6 for ; Mon, 2 Sep 2024 21:53:36 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id D91C340280 for ; Tue, 3 Sep 2024 01:53:35 +0000 (UTC) X-FDA: 82521755190.16.FDAA0A7 Received: from mail-vk1-f175.google.com (mail-vk1-f175.google.com [209.85.221.175]) by imf18.hostedemail.com (Postfix) with ESMTP id 0B4281C0008 for ; Tue, 3 Sep 2024 01:53:33 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=none; spf=pass (imf18.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.175 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=kernel.org (policy=quarantine) ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725328366; a=rsa-sha256; cv=none; b=GtWLh1X/Cj59c2YNtn92fj6Q6g+C/fUPufowuMYAQzsXibkKYRDVHAtD34b+6BljGbACG/ h0Z/DtkwKF7J9/YBx/fl5TyhBtYA/qvz83eSxLdO23uk7bidMmj6Wfhyzz53V/3MXup2Ta p1WkBpE2WoRdAABdkoqypxySFmw7Cuc= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=none; spf=pass (imf18.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.175 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=kernel.org (policy=quarantine) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1725328366; 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=Ea+bFyqFSX+YxQSwCO+mp9wllj7zkTS/6Y/bdTrmbnE=; b=th+1KFenw+aGqcipImefxQ2mGHY181GPXr83eow9uWENTQ+08oepQWS0y2Q3tN2/A6l2HG o4hzkbZnUgTYwvEYo0nqb63bvBTR/nZuXxI+dJd7KcMirpwvcpjtQ+va47HMtccsE5i7+o CpmREC0sYhKlKaRXgCr4d2QoNZeKwaE= Received: by mail-vk1-f175.google.com with SMTP id 71dfb90a1353d-4fcff944d1dso1372347e0c.0 for ; Mon, 02 Sep 2024 18:53:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725328413; x=1725933213; 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=Ea+bFyqFSX+YxQSwCO+mp9wllj7zkTS/6Y/bdTrmbnE=; b=iuC4+49OAE7FggNQ4DXV9B5f8BypwxcJOT7namBXceiQz5QucavrwpUC4TZVdtzpMu U5kp2EYuzrnEAup38MrdGs4dqYCaSjlGhZ/jvex87gikUESNm3Yy7i9fqK5HhRj52SnH 9dpDPVLXkmyTs4LaMeLNKJYq7tU2SFhW3rg/qVgvuH9MrBUCJ85SCgE2KIKFukSrVvlg ISRMF1+37dbTCZvGX21WB6IpwdlRFETAqkBmADfJ70FhlBn/1MM/QnwZ3x5hwGmPDrRl rFUwcdS4keXrUo41022JfptiWW2KmTARu2STeeoYvXdly3aFT8y+/EkyO4hQvYeUdo3n 85ow== X-Forwarded-Encrypted: i=1; AJvYcCU1A3LlaQjSa9Smx+3bMPS8s2gisr/hX/HhUBdYmsEjinbMmdzmPRJKRyqjYm+g13Cem+G9WgGSvg==@kvack.org X-Gm-Message-State: AOJu0Yx+1kRHcvA7oA7XJdqe5zKwmMkXGp18r3YJYw2P3eRwxrgFTaBo RX2WEcjYA93yn/mRrM+kn2TpXRVt/Yh//FEe6U7RIm17FLJdKS4U3naFwypJu1VbS0bp6Oq/NqX po9EzlD+1a4xrTTWVA0V0mjN/Kos= X-Google-Smtp-Source: AGHT+IEgKdUnhNq1npQpz3q2eThJQZa2L0vd6jhGuNeLVLkRSpCbCraK+pLcXhqC1+Ah1Ay9wP0CS0ob0E+kovlrdbc= X-Received: by 2002:a05:6122:20a1:b0:4f5:2276:1366 with SMTP id 71dfb90a1353d-4ffe4a58f0dmr14431497e0c.3.1725328413013; Mon, 02 Sep 2024 18:53:33 -0700 (PDT) MIME-Version: 1.0 References: <20240808111849.651867-1-ryan.roberts@arm.com> <20240808111849.651867-3-ryan.roberts@arm.com> <747d1319-f746-4379-bf88-a0f6c3f558b4@linux.alibaba.com> <14823123-79e3-4c7d-8501-8c46c6ec13c7@arm.com> In-Reply-To: From: Barry Song Date: Tue, 3 Sep 2024 13:53:21 +1200 Message-ID: Subject: Re: [PATCH v3 2/2] mm: Tidy up shmem mTHP controls and stats To: Baolin Wang Cc: Ryan Roberts , Andrew Morton , Hugh Dickins , "Matthew Wilcox (Oracle)" , David Hildenbrand , Lance Yang , Gavin Shan , linux-kernel@vger.kernel.org, linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 0B4281C0008 X-Stat-Signature: rokxnyziwkbgiu13s9e9k1nqg98k3x8j X-Rspam-User: X-Rspamd-Pre-Result: action=add header; module=dmarc; Action set by DMARC X-Rspam: Yes X-HE-Tag: 1725328413-930514 X-HE-Meta: U2FsdGVkX1/GaNHCbAu1XYvpU3QmEKZHpnInkg+1RL0FyNCy2kUK1sCfgytP2GllLvqYW4xM+GJCPfnwEVG0Ng5uIDQXju4wzMgQZeGEplqntcLKmUBN52UgN0s9suvulFluL/gaON/WDk9I/QP2Fes85Vu6hzFCy3hCy0VywLXweaB+PvZvCGPvVJuLCL8XDrHGrv4Q79G0Fra9AoZEXYzLpE2va35rlnyBIr2osRzysxNCV6eX06KmjN3y6Njy6rtSPu0LXbnVmMS3LJl7VbjDEXC2CQGWvj/sRRBgBNrKTN3saWrDbZaWy1+6/1B2gAkNuDvCt+uU/yn2puVpMGhsZh0bFHvV5VvR4S9NYefyQjNwqD/X7JrQpkecErDV3fZsT/uBint00IjF7bqllx067jIwd8PXRRhOHGpBdiy8BX/lvq9NTAIoONRh6TGRIp7dIMmkPlRIf4rbMS5X3ATY7fzrktboHggqN5VKHKX4imRcZrAM6PzPTn18eKNG855h0lVOxc1P9JeTNY2iYq56SQC4fb+viCLKF/6CmAoT1jXlq926jtzjuHrdM40kJvix6CIqrYpmhHQNI8pG9IMFJ/fmeRP389lvP/NBIdycWJqQAYaJsliQ6a3VtZ4SQkrzZdns3YijtfaX+xXET6cpzG2BSa9dbtD75lYFWHGEKta6nI/Ar5CJ/M3OWv6+zmamj7FjDGbyszLmmMqlC+skWUXUowxOsR5Jh7xL6iYNGyyQLoaS7vZ2c6h5Q0V55Ma1uwqfws27mk1F7WBOCIzeO5qeHdXF4Q8TpX+yLCY3Y3pv8Sm8eESfQYO/+dGttP3FD5YBOohaB2AfUBAQEroynM+2vR8ElZ5SV36MOeADH2wjZZ4NdOYPDG/E1uDGOyM6+w+IEr97a1JA4vL0EWylzH1GRbwp3XlviNfSE79Tk+fO4lCD++rD1iHBp3yY9vDVk1JLHjLslesDEy1 dXcjQQ8Z YsMUjKIRuQC2tvkcVgmIO3pwekru1PQIcmWf/bkWgIT3PL2jeWkx8g0TPd/pGWzs4W4hQwEAUcMRakJVzQS8vdPg17R5wnkctgZ8SoAAd81uutEgGe8w1f3ZeCPR/mNU2WHHBnqQKDiOgl/xMtQeY/zW6n33HwK6PGOTqU7pE6a0cc0P8uItQDQr5JMR45BCJ0uSkWeOGMOfDz8UJcjvc79H5XayTi58He8HiM7sxNeHcJWRDL0qe28qbK5zHpkxsoZK0LoFj0u2FrQJEaXA9EQA05ppI6whEgyz38CAR1HVVA+ZWNELWX8HlRqm04+FXepc5/z79MFFQlfmUYl6po2lBEQpNfT6z5hNzdlzfml0nL+zJctKSvSNBtg== 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 Tue, Sep 3, 2024 at 1:15=E2=80=AFPM Baolin Wang wrote: > > > > On 2024/9/2 17:58, Ryan Roberts wrote: > > Hi Baolin, > > > > Thanks for the review - I've been out on Paternity leave so only gettin= g around > > to replying now... > > No worries :) > > > On 09/08/2024 09:31, Baolin Wang wrote: > >> > >> > >> On 2024/8/8 19:18, Ryan Roberts wrote: > >>> Previously we had a situation where shmem mTHP controls and stats wer= e > >>> not exposed for some supported sizes and were exposed for some > >>> unsupported sizes. So let's clean that up. > >>> > >>> Anon mTHP can support all large orders [2, PMD_ORDER]. But shmem can > >>> support all large orders [1, MAX_PAGECACHE_ORDER]. However, per-size > >>> shmem controls and stats were previously being exposed for all the an= on > >>> mTHP orders, meaning order-1 was not present, and for arm64 64K base > >>> pages, orders 12 and 13 were exposed but were not supported internall= y. > >>> > >>> Tidy this all up by defining ctrl and stats attribute groups for anon > >>> and file separately. Anon ctrl and stats groups are populated for all > >>> orders in THP_ORDERS_ALL_ANON and file ctrl and stats groups are > >>> populated for all orders in THP_ORDERS_ALL_FILE_DEFAULT. > >>> > >>> Additionally, create "any" ctrl and stats attribute groups which are > >>> populated for all orders in (THP_ORDERS_ALL_ANON | > >>> THP_ORDERS_ALL_FILE_DEFAULT). swpout stats use this since they apply = to > >>> anon and shmem. > >>> > >>> The side-effect of all this is that different hugepage-*kB directorie= s > >>> contain different sets of controls and stats, depending on which memo= ry > >>> types support that size. This approach is preferred over the > >>> alternative, which is to populate dummy controls and stats for memory > >>> types that do not support a given size. > >>> > >>> Signed-off-by: Ryan Roberts > >>> --- > >>> mm/huge_memory.c | 144 +++++++++++++++++++++++++++++++++++++------= ---- > >>> 1 file changed, 114 insertions(+), 30 deletions(-) > >>> > >>> diff --git a/mm/huge_memory.c b/mm/huge_memory.c > >>> index 0c3075ee00012..082d86b7c6c2f 100644 > >>> --- a/mm/huge_memory.c > >>> +++ b/mm/huge_memory.c > >>> @@ -482,8 +482,8 @@ static void thpsize_release(struct kobject *kobj)= ; > >>> static DEFINE_SPINLOCK(huge_anon_orders_lock); > >>> static LIST_HEAD(thpsize_list); > >>> -static ssize_t thpsize_enabled_show(struct kobject *kobj, > >>> - struct kobj_attribute *attr, char *buf) > >>> +static ssize_t anon_enabled_show(struct kobject *kobj, > >>> + struct kobj_attribute *attr, char *buf) > >>> { > >>> int order =3D to_thpsize(kobj)->order; > >>> const char *output; > >>> @@ -500,9 +500,9 @@ static ssize_t thpsize_enabled_show(struct kobjec= t *kobj, > >>> return sysfs_emit(buf, "%s\n", output); > >>> } > >>> -static ssize_t thpsize_enabled_store(struct kobject *kobj, > >>> - struct kobj_attribute *attr, > >>> - const char *buf, size_t count) > >>> +static ssize_t anon_enabled_store(struct kobject *kobj, > >>> + struct kobj_attribute *attr, > >>> + const char *buf, size_t count) > >>> { > >>> int order =3D to_thpsize(kobj)->order; > >>> ssize_t ret =3D count; > >>> @@ -544,19 +544,35 @@ static ssize_t thpsize_enabled_store(struct kob= ject *kobj, > >>> return ret; > >>> } > >>> -static struct kobj_attribute thpsize_enabled_attr =3D > >>> - __ATTR(enabled, 0644, thpsize_enabled_show, thpsize_enabled_stor= e); > >>> +static struct kobj_attribute anon_enabled_attr =3D > >>> + __ATTR(enabled, 0644, anon_enabled_show, anon_enabled_store); > >>> -static struct attribute *thpsize_attrs[] =3D { > >>> - &thpsize_enabled_attr.attr, > >>> +static struct attribute *anon_ctrl_attrs[] =3D { > >>> + &anon_enabled_attr.attr, > >>> + NULL, > >>> +}; > >>> + > >>> +static const struct attribute_group anon_ctrl_attr_grp =3D { > >>> + .attrs =3D anon_ctrl_attrs, > >>> +}; > >>> + > >>> +static struct attribute *file_ctrl_attrs[] =3D { > >>> #ifdef CONFIG_SHMEM > >>> &thpsize_shmem_enabled_attr.attr, > >>> #endif > >>> NULL, > >>> }; > >>> -static const struct attribute_group thpsize_attr_group =3D { > >>> - .attrs =3D thpsize_attrs, > >>> +static const struct attribute_group file_ctrl_attr_grp =3D { > >>> + .attrs =3D file_ctrl_attrs, > >>> +}; > >>> + > >>> +static struct attribute *any_ctrl_attrs[] =3D { > >>> + NULL, > >>> +}; > >>> + > >>> +static const struct attribute_group any_ctrl_attr_grp =3D { > >>> + .attrs =3D any_ctrl_attrs, > >>> }; > >> > >> I wonder why adding a NULL group? > > > > It made everything a bit more generic and therefore extensible. Its my > > preference to leave it as is, but will remove it if you insist. > > My preference is we should add it when necessary, but but I don't have a > strong opinion. Let's see what other guys prefer, David, Barry? I'm fine with either option. Adding a NULL control group makes it easier for lazy people like me to understand the current status, as it clearly indicates that there isn't a shared control group for file, shmem, and anon at the moment. :-) Thanks Barry