From: Lorenzo Stoakes <ljs@kernel.org>
To: ranxiaokai627@163.com
Cc: akpm@linux-foundation.org, baolin.wang@linux.alibaba.com,
hughd@google.com, leitao@debian.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
ran.xiaokai@zte.com.cn
Subject: Re: [PATCH v2 2/2] mm: huge_memory: refactor thpsize_shmem_enabled_show() with helper arrays
Date: Fri, 15 May 2026 12:36:10 +0100 [thread overview]
Message-ID: <agcEzrqJlyxMeM35@lucifer> (raw)
In-Reply-To: <20260515060441.53094-1-ranxiaokai627@163.com>
On Fri, May 15, 2026 at 06:04:41AM +0000, ranxiaokai627@163.com wrote:
> >(As I said in the 1/2)
> >
> >Please don't send 2/2 in response to 1/2, and use a cover letter if you send
> >more than 1 patch!
>
> Thanks for the guidance.
> I will do that in the next verison.
>
> >On Wed, May 13, 2026 at 09:45:08AM +0000, ranxiaokai627@163.com wrote:
> >> From: Ran Xiaokai <ran.xiaokai@zte.com.cn>
> >>
> >> Replace the hardcoded if/else chain of test_bit() calls and string
> >> literals in thpsize_shmem_enabled_show() with a loop over
> >> huge_shmem_orders_by_mode[] and huge_shmem_enabled_mode_strings[] arrays.
> >>
> >> This makes thpsize_shmem_enabled_show() consistent with
> >> thpsize_shmem_enabled_store() and eliminates duplicated mode name strings.
> >>
> >> Signed-off-by: Ran Xiaokai <ran.xiaokai@zte.com.cn>
> >
> >The logic looks good, I wish we could de-duplicate. But for now maybe better to
> >get this refactored first.
> >
> >So:
> >
> >Reviewed-by: Lorenzo Stoakes <ljs@kernel.org>
> >
> >> ---
> >> mm/shmem.c | 36 +++++++++++++++++++++++-------------
> >> 1 file changed, 23 insertions(+), 13 deletions(-)
> >>
> >> diff --git a/mm/shmem.c b/mm/shmem.c
> >> index 60cb10854f11..086762e6de71 100644
> >> --- a/mm/shmem.c
> >> +++ b/mm/shmem.c
> >> @@ -5553,20 +5553,30 @@ static ssize_t thpsize_shmem_enabled_show(struct kobject *kobj,
> >> struct kobj_attribute *attr, char *buf)
> >> {
> >> int order = to_thpsize(kobj)->order;
> >> - const char *output;
> >> -
> >> - if (test_bit(order, &huge_shmem_orders_always))
> >> - output = "[always] inherit within_size advise never";
> >> - else if (test_bit(order, &huge_shmem_orders_inherit))
> >> - output = "always [inherit] within_size advise never";
> >> - else if (test_bit(order, &huge_shmem_orders_within_size))
> >> - output = "always inherit [within_size] advise never";
> >> - else if (test_bit(order, &huge_shmem_orders_madvise))
> >> - output = "always inherit within_size [advise] never";
> >> - else
> >> - output = "always inherit within_size advise [never]";
> >> + int active = HUGE_SHMEM_ENABLED_NEVER;
> >> + int len = 0;
> >> + int i;
> >> +
> >> + for (i = 0; i < ARRAY_SIZE(huge_shmem_orders_by_mode); i++) {
> >> + if (test_bit(order, huge_shmem_orders_by_mode[i])) {
> >> + active = i;
> >> + break;
> >> + }
> >> + }
> >> +
> >> + for (i = 0; i < ARRAY_SIZE(huge_shmem_enabled_mode_strings); i++) {
> >> + if (i == active)
> >> + len += sysfs_emit_at(buf, len, "[%s] ",
> >> + huge_shmem_enabled_mode_strings[i]);
> >> + else
> >> + len += sysfs_emit_at(buf, len, "%s ",
> >> + huge_shmem_enabled_mode_strings[i]);
> >> + }
> >> +
> >> + /* Replace trailing space with newline */
> >> + buf[len - 1] = '\n';
> >>
> >> - return sysfs_emit(buf, "%s\n", output);
> >> + return len;
> >> }
> >
> >This is pretty mcuh a one-for-one copy/pasta of defrag_show(), I don't love that
> >we have the exact same code duplicated across two files like that.
> >
> >You could write something like:
> >
> >static ssize_t thp_sysfs_enabled_show(struct kobject *kobj,
> > struct kobj_attribute *attr, char *buf,
> > const char *names, int names_len,
> > const char *orders_by_mode, int orders_by_mode_len,
> > int default_mode)
> >{
> > ...
> >}
> >
> >To abstract it, but that's kind of a horrible signature isn't it? :)
> >
> >Could use a helper struct, but that feels a bit overkill for this hmm...
> >
> >Really I wonder if we shouldn't have this in huge_memory.c anyway, it's a bit of
> >a weird thing to put it in mm/shmem.c, it's more huge pages than shmem imo.
> >
> >Anyway. The logic itself looks fine so LGTM!
>
> Yes, after this patch is applied, the read/write handlers for the
> shmem_enabled and enabled interfaces will have a lot of duplicated code.
> I will continue to investigate whether we can abstract a more generic
> function to handle both interfaces.
> Introducing a helper struct as a parameter is a good inspiration.
Well it'd probably be overkill :)
For the time being, let's not do that, and just get this change in (with other
changes suggested applied of course), so send a respin without that please.
I think it's more important to address the hideous duplication we have _right
now_ rather than optimising deduplicating this code :) we can always do that
later.
Cheers, Lorenzo
>
> >>
> >> static ssize_t thpsize_shmem_enabled_store(struct kobject *kobj,
> >> --
> >> 2.25.1
> >>
> >>
> >
> >Cheers, Lorenzo
>
next prev parent reply other threads:[~2026-05-15 11:36 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-13 9:45 [PATCH v2 1/2] mm: huge_memory: refactor thpsize_shmem_enabled_store() with sysfs_match_string() ranxiaokai627
2026-05-13 9:45 ` [PATCH v2 2/2] mm: huge_memory: refactor thpsize_shmem_enabled_show() with helper arrays ranxiaokai627
2026-05-14 2:41 ` Baolin Wang
2026-05-14 9:08 ` Breno Leitao
2026-05-14 12:22 ` Lorenzo Stoakes
2026-05-15 6:04 ` ranxiaokai627
2026-05-15 11:36 ` Lorenzo Stoakes [this message]
2026-05-14 2:36 ` [PATCH v2 1/2] mm: huge_memory: refactor thpsize_shmem_enabled_store() with sysfs_match_string() Baolin Wang
2026-05-14 10:10 ` ranxiaokai627
2026-05-14 12:05 ` Lorenzo Stoakes
2026-05-14 8:33 ` Breno Leitao
2026-05-14 9:26 ` ranxiaokai627
2026-05-14 12:48 ` Lorenzo Stoakes
2026-05-15 6:21 ` ranxiaokai627
2026-05-15 7:23 ` ranxiaokai627
2026-05-15 11:34 ` Lorenzo Stoakes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=agcEzrqJlyxMeM35@lucifer \
--to=ljs@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=hughd@google.com \
--cc=leitao@debian.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ran.xiaokai@zte.com.cn \
--cc=ranxiaokai627@163.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.