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 143B8C54FC6 for ; Tue, 3 Sep 2024 01:15:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 517008D011F; Mon, 2 Sep 2024 21:15:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4C7BB8D00E7; Mon, 2 Sep 2024 21:15:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3DF868D011F; Mon, 2 Sep 2024 21:15:51 -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 1E4FE8D00E7 for ; Mon, 2 Sep 2024 21:15:51 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 8FD30A08D4 for ; Tue, 3 Sep 2024 01:15:50 +0000 (UTC) X-FDA: 82521660060.08.BE5AA83 Received: from out30-132.freemail.mail.aliyun.com (out30-132.freemail.mail.aliyun.com [115.124.30.132]) by imf04.hostedemail.com (Postfix) with ESMTP id 1706D40006 for ; Tue, 3 Sep 2024 01:15:46 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=SwPdd3vU; dmarc=pass (policy=none) header.from=linux.alibaba.com; spf=pass (imf04.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.132 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725326125; a=rsa-sha256; cv=none; b=fV4xY2OaPGsF/uFW4Zi4BvQHz9PmqtWVsXoHJFPtRGmtHD5572CKyirSK9u0rvrHn09reT bSh/2bfMwcvhWQ36SNejBnlUj9f+e+qlUUBgb5DGPtF7BSp0tYIUDCUuL0ivzpsRyM7XL2 UCjGg9i/GA1pWZODXC8jOM+tSG1KNGE= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=SwPdd3vU; dmarc=pass (policy=none) header.from=linux.alibaba.com; spf=pass (imf04.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.132 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1725326125; 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=TzlklaidYy3eFIkRP9DWHLpTDbs7aAqmDcAR3JaO49M=; b=KAA9xHo1aGKT8XvvzSloBjwaXOw9iiDGytbeBo5YqWOebQ7MD696gaXr+/Z8mNzQ8E0mYX exjgrqeGvR2SjaZfAE70KmFAfvpBA2Yb1S+0P+sSogsZ/+So8jVqZQjkleS6XETXNfwFu0 iV9DovnyEK7Lbe02PtuNvpQaWSF/PvA= DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1725326143; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=TzlklaidYy3eFIkRP9DWHLpTDbs7aAqmDcAR3JaO49M=; b=SwPdd3vUKIm/BjgIDuTinYYCAoqzzbBWdFbM8bXsSYRqQYVqR73JoxhJkDQctTha+dGM66HKKQopE9DyVSJ56DgKwFb73fCw8UMNSVssSggt9VH9RJCg0Q6AQYTXwwni6iB5LnHL1umexdwdQU7Bm7EM/MEHS+0vGn3mG6G3ojk= Received: from 30.74.144.108(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0WEBErgJ_1725326141) by smtp.aliyun-inc.com; Tue, 03 Sep 2024 09:15:41 +0800 Message-ID: Date: Tue, 3 Sep 2024 09:15:39 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 2/2] mm: Tidy up shmem mTHP controls and stats To: Ryan Roberts , Andrew Morton , Hugh Dickins , "Matthew Wilcox (Oracle)" , David Hildenbrand , Barry Song , Lance Yang , Gavin Shan Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org 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> From: Baolin Wang In-Reply-To: <14823123-79e3-4c7d-8501-8c46c6ec13c7@arm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Queue-Id: 1706D40006 X-Rspamd-Server: rspam01 X-Stat-Signature: wps8qtqkxw4mwixiahbb4sonjm3h5uzw X-HE-Tag: 1725326146-743915 X-HE-Meta: U2FsdGVkX1+XjFUqziewE82teZSycWvkXH92Qif4mVWJMhX9He8LyfVzcWnyxEni7drIx1xD6lvx27dld/B54AqIYmyr208xHzILfNYlhffUTF1tBH7ps2IXMuD1QZx7lmbazmo6YorBMdJWtkak1+TOvoENAog2KJqw6NzcVbSSaup5gVH0m+qfRIq10OgXW9aM1gtrXh9FpZ747AZZ5wErhV8HeqEZ72FcBtKML0W5ba8SB6RJndCSzSxntM8IUodukgYiUtNAfmUZwXa9bx2dJZsBctNSDk5FVOrtXtkzukwyutTgT3WC9vEzWjZehZbSaLbIhMj66EXfQDzpHWEdhALR3uQwlk8BiRUV598hTP2x1lK4mGh6sulJF5MKHhZo6UB8pYDS/6m3p1z6k4GKBMhqaI+08W2QhKtebYffjy6ECzu4M0DHUcOa6Gm5WrL2rPS5hW/0zjDuylwq1vVqQnU/aosC+J24TzpD01Xrc3EtjiHNxh7SKMlYgBzAFsS47HbJcEJacjpj3s0I2C7nIps0hToy2nQKyYH9HUvZeGxlh3cdNvxptUEB2V8dOOXYWNLeAqsQo2FUYZThK4w/cBrQ0KTW1iua7x/6hUSxaIlzry/rSMjbYMT3GItBOv4tTnamA7rWdGYyLToCDFVlyGE5RFT8KCrI3Wbo607b0Va4FPBU9jM51PtSxr7T3qynQERdz8ct8Q0XrYvLMzMDn3pbNN+Pf56vY+50EV8cXngYlPT8Sj/1BOjgaC3BALziBKnryfasTMGoXHaTTy9sg9jkUXFeEm4nQnYZeNyK1W+zAyaUEnfFul7t0TDN2f74hhbxsSIgwefZdhlVP6a7Zd2O+mLUEAVdSb2/p7DqqkpA9epGjsGfOZxtj0dZGIMvmSzGWeuLVYg7rnD2Kof7NIElru0fm1AoJCDciAW7S4AYRJAWjIHL3ANK61JZlGA9weh/9jiJTKvl4Cs oTmo4cQk 7F07om7RqZB36a/pnq7XKGqMVhofoTyS75tk6iIgI6jHw6OtSppheH6EjZGUO0GLuyds42PiT/83f1dpyXOFg1YiFiUwJnGs2r12S0RcPpYz4eQkfzS8LXN/Jg8R2u8+6VhwKSckFVFFw76yDK8EMn54SynnDTZkcISx9H8pAzQAoeZwXcn2+67wngjhgXar3hmT/zAtpXn47EKdggHrIo5Hu02/4oUvJhPKIUrlX9YKe/j9NRoyASNRioTrJYJgxaF6bBut3q50VzAV+jYk0LfhOv6El2t7YV70OqdPCunT3XhqKHcVEXWcwf5Ab5g8Opy8K0EKIYPQoX2QJ2Wt+bI1P4Q== 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 2024/9/2 17:58, Ryan Roberts wrote: > Hi Baolin, > > Thanks for the review - I've been out on Paternity leave so only getting 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 were >>> 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 anon >>> mTHP orders, meaning order-1 was not present, and for arm64 64K base >>> pages, orders 12 and 13 were exposed but were not supported internally. >>> >>> 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 directories >>> contain different sets of controls and stats, depending on which memory >>> 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 = to_thpsize(kobj)->order; >>>       const char *output; >>> @@ -500,9 +500,9 @@ static ssize_t thpsize_enabled_show(struct kobject *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 = to_thpsize(kobj)->order; >>>       ssize_t ret = count; >>> @@ -544,19 +544,35 @@ static ssize_t thpsize_enabled_store(struct kobject *kobj, >>>       return ret; >>>   } >>>   -static struct kobj_attribute thpsize_enabled_attr = >>> -    __ATTR(enabled, 0644, thpsize_enabled_show, thpsize_enabled_store); >>> +static struct kobj_attribute anon_enabled_attr = >>> +    __ATTR(enabled, 0644, anon_enabled_show, anon_enabled_store); >>>   -static struct attribute *thpsize_attrs[] = { >>> -    &thpsize_enabled_attr.attr, >>> +static struct attribute *anon_ctrl_attrs[] = { >>> +    &anon_enabled_attr.attr, >>> +    NULL, >>> +}; >>> + >>> +static const struct attribute_group anon_ctrl_attr_grp = { >>> +    .attrs = anon_ctrl_attrs, >>> +}; >>> + >>> +static struct attribute *file_ctrl_attrs[] = { >>>   #ifdef CONFIG_SHMEM >>>       &thpsize_shmem_enabled_attr.attr, >>>   #endif >>>       NULL, >>>   }; >>>   -static const struct attribute_group thpsize_attr_group = { >>> -    .attrs = thpsize_attrs, >>> +static const struct attribute_group file_ctrl_attr_grp = { >>> +    .attrs = file_ctrl_attrs, >>> +}; >>> + >>> +static struct attribute *any_ctrl_attrs[] = { >>> +    NULL, >>> +}; >>> + >>> +static const struct attribute_group any_ctrl_attr_grp = { >>> +    .attrs = 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?