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 96D85CA0ED3 for ; Wed, 4 Sep 2024 10:18:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0F77D6B0299; Wed, 4 Sep 2024 06:18:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0A6D96B029B; Wed, 4 Sep 2024 06:18:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E8A536B029D; Wed, 4 Sep 2024 06:18:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id C5EF26B0299 for ; Wed, 4 Sep 2024 06:18:50 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id D8EA71A0FC4 for ; Wed, 4 Sep 2024 10:18:49 +0000 (UTC) X-FDA: 82526657178.07.C452F58 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf26.hostedemail.com (Postfix) with ESMTP id 0378B14000F for ; Wed, 4 Sep 2024 10:18:47 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=none; spf=pass (imf26.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1725445080; 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=XM+J2keQdsStc3t5lOw8JWE/LdDKGym6o7v6NpomE7E=; b=NC5tx1My54EHgSGd5CmFN+mCZNIu2BlJfHGAq238yGP63ZovZeNIpGZdnBx12lV++gSjq2 paa8jwzk8PysQqk75YXwU+NJcSLkdnJcQLyyzvFg+olGGuvIcI0LZOPMGWUdB/RLwW+Dl6 ACXE1T/MvG1hcrr3Q0b1tCSdVqePETk= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=none; spf=pass (imf26.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725445080; a=rsa-sha256; cv=none; b=dqiU3T6Km8CJrn2XuBliwAA9MyM5Jcs6g6k3oO+NM56DxKY3/mDsn8eXC4v+U9d1oC/5eu Kij9cTa0I/7SKDyRcnrMzpNH8H23AS8kcadOlrPzE2SZOSZX9oQxSWEWcsk2YwQlbn7s5r ihUhTkY/68eb9iyryLxA+K52OL9/gUM= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 8B552FEC; Wed, 4 Sep 2024 03:19:13 -0700 (PDT) Received: from [10.57.87.65] (unknown [10.57.87.65]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A01EC3F66E; Wed, 4 Sep 2024 03:18:45 -0700 (PDT) Message-ID: <069185e0-80db-46a7-8852-2381db28cc97@arm.com> Date: Wed, 4 Sep 2024 11:18:44 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 2/2] mm: Tidy up shmem mTHP controls and stats Content-Language: en-GB To: Barry Song , Baolin Wang Cc: Andrew Morton , Hugh Dickins , "Matthew Wilcox (Oracle)" , David Hildenbrand , Lance Yang , Gavin Shan , 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: Ryan Roberts In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 0378B14000F X-Stat-Signature: hmdpe71rtcwow79xzma9ngdhyim1kmdy X-HE-Tag: 1725445127-897341 X-HE-Meta: U2FsdGVkX1/aWUnU79PlNdbw+epaHIPSENuoU8Prj53XPy8cjvB7idNI2YetdJ9NvHUshu3MPq1/HateXio3IWVHEKTrK+aDIhOTZllSU1gLdAOcM4dIV6hWRqh1wDSnI4bj3+rcu5vu/PExl+pFWjsTfKKOijjUVo20GkPvpOgJf+xahpQWcM7fvhTYI+t2CMc9HaczPyr1pNNCD/FB57pg0I7xhV6zBWNSW9RfLTpJdVpdPEbpbkCTPdWl1Ge/ZD+/UfC4S0Ro6uit52NgP2amSXu1Eb86uVwmVhx3G9X6H4Kn322K94ikd9GhA7uJCZlRi1si30UWMyyS+NXyAivOK9R/BsKPAMC+wvrpF+U53tT86xwNaEpml07zP0q2KVRv6WoMZgArFVcTS9BjLr6BAEVu+bjyX2todtLjP4+q4cRJOkO4QKbrobB1eeLrc2iHJMvQ5zWW2ry37eQwTj+Xv+L1bAcOhf2H56Kii8ulNNHgtSbD2pitemt7iIxY/axz85IpKibMw8fy6M9VSigEAtnyLbUo7r2kQPGaYQ74Ub1tBuqT1qgMqhKerouiW5CdXVgy1eKGO7TsTbJlI87y12d4dhanBJ1rouZbeKntWpubpz3rAxR4mcA5t/EfVcj/9m6cimEWrIUWBvj9yT1yAyRzmg2UGYMwUu06+i6z8bM23+6zrehQHEpA1isRpkBiqZfWCO3IiCM3gYtYllOAqU22ymhQCyB3WFO3bh35/XRUD0P+aq1mguRLwTpSaBPJIa1WVj0U2m1DdK3KHTKx+poPd5uedTy8siZ4Sh43PQbRS0VK6C8rbvvgYYIwncexFA0ivjxmuKTcEjEblvxkOnFa+Y8H3HSXFf2oEGwy0qaDnzfP4ZglIPgxh1SyZDnNYgCUW2phC4J2t9++BfyzxQXn1hd/a2q+cE7GlNRudJATn2m8rsXUzXgQlS667Aia/+4/J+s39WgXIvC tCvZC0mp c8twlZSV0+NE+2avLdA7LMn9NCKO0L0sTalfXBsJIJAefhxeRLAqmO35xzT8ruGu9HmgEty0WvdLy/md/PPCYvDz0vrX1bdso9i3U7gbnaWlciMSa7tuaKpoViKEPmTZG5KVoJypH0qx371rarwS8TW0b70PxfimR+w7yupgWY0fzI/FftGapBg/mQO3sjLUieViWT8GdWuoD+bxy85WFOy0g7AeXEDt55Ud2Ve0/Bo40trfESehDxYkFqRbPvchBAd0i 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 03/09/2024 02:53, Barry Song wrote: > On Tue, Sep 3, 2024 at 1:15 PM 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 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? > > 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 for the feedback, I'm going to leave it as is in the next version then. > > Thanks > Barry