Re: [PATCH v3 2/2] mm: Tidy up shmem mTHP controls and stats

[Ryan Roberts]

On 03/09/2024 02:53, Barry Song wrote:
> On Tue, Sep 3, 2024 at 1:15 PM Baolin Wang
> <baolin.wang@xxxxxxxxxxxxxxxxx> 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 <ryan.roberts@xxxxxxx>
>>>>> ---
>>>>>    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