From: Joshua Hahn <joshua.hahnjy@gmail.com>
To: "Huang, Ying" <ying.huang@linux.alibaba.com>
Cc: gourry@gourry.net, honggyu.kim@sk.com, yunjeong.mun@sk.com,
gregkh@linuxfoundation.org, rafael@kernel.org, lenb@kernel.org,
dan.j.williams@intel.com, Jonathan.Cameron@huawei.com,
dave.jiang@intel.com, horen.chuang@linux.dev, hannes@cmpxchg.org,
osalvador@suse.de, linux-kernel@vger.kernel.org,
linux-acpi@vger.kernel.org, linux-mm@kvack.org,
kernel-team@meta.com
Subject: Re: [PATCH v8] mm/mempolicy: Weighted Interleave Auto-tuning
Date: Sat, 10 May 2025 11:51:50 -0700 [thread overview]
Message-ID: <20250510185150.4078843-1-joshua.hahnjy@gmail.com> (raw)
In-Reply-To: <87h61t11gz.fsf@DESKTOP-5N7EMDA>
On Sat, 10 May 2025 13:25:32 +0800 "Huang, Ying" <ying.huang@linux.alibaba.com> wrote:
Hi Ying,
Thank you for reviewing my patch, as always!
> Hi, Joshua,
>
> Thank you for updated version! And sorry for late reply.
>
> Joshua Hahn <joshua.hahnjy@gmail.com> writes:
[...snip...]
> > diff --git a/Documentation/ABI/testing/sysfs-kernel-mm-mempolicy-weighted-interleave b/Documentation/ABI/testing/sysfs-kernel-mm-mempolicy-weighted-interleave
> > index 0b7972de04e9..ec13382c606f 100644
> > --- a/Documentation/ABI/testing/sysfs-kernel-mm-mempolicy-weighted-interleave
> > +++ b/Documentation/ABI/testing/sysfs-kernel-mm-mempolicy-weighted-interleave
> > @@ -20,6 +20,35 @@ Description: Weight configuration interface for nodeN
> > Minimum weight: 1
> > Maximum weight: 255
> >
> > - Writing an empty string or `0` will reset the weight to the
> > - system default. The system default may be set by the kernel
> > - or drivers at boot or during hotplug events.
> > + Writing invalid values (i.e. any values not in [1,255],
> > + empty string, ...) will return -EINVAL.
> > +
> > + Changing the weight to a valid value will automatically
> > + update the system to manual mode as well.
>
> s/update/switch/ ?
>
> But my English is poor, please keep your version if you think that it's
> better.
I have no particular preference here, whatever will make it easiest for the
users to understand what is happening. I'll take your suggestion!
[...snip...]
> > +/*
> > + * A null weighted_interleave_state is interpted as having .mode = "auto",
> > + * and .iw_table is interpreted as an array of 1s with length nr_node_ids.
> > + */
>
> Better to move the comments to above "wi_state" definition?
>
> > +struct weighted_interleave_state {
> > + bool mode_auto;
> > + u8 iw_table[];
> > +};
> > +
>
> Why do you put the type definition in mempolicy.h instead of
> mempolicy.c? I don't find other users except mempolicy.c.
Good point, I'll move the definition to mempolicy.c and move the comment
to the wi_state definition as well.
[...snip...]
> > @@ -3450,31 +3555,104 @@ static ssize_t node_show(struct kobject *kobj, struct kobj_attribute *attr,
> > static ssize_t node_store(struct kobject *kobj, struct kobj_attribute *attr,
> > const char *buf, size_t count)
> > {
> > + struct weighted_interleave_state *new_wi_state, *old_wi_state = NULL;
> > struct iw_node_attr *node_attr;
> > - u8 *new;
> > - u8 *old;
> > u8 weight = 0;
> > + int i;
> >
> > node_attr = container_of(attr, struct iw_node_attr, kobj_attr);
> > if (count == 0 || sysfs_streq(buf, ""))
> > weight = 0;
>
> According to revised ABI, we should return -EINVAL here?
Great catch, I completely ignored the ABI description that I wrote...
I'll go ahead and just return -EINVAL here!
[...snip...]
> > +static ssize_t weighted_interleave_auto_store(struct kobject *kobj,
> > + struct kobj_attribute *attr, const char *buf, size_t count)
> > +{
> > + struct weighted_interleave_state *new_wi_state, *old_wi_state = NULL;
> > + unsigned int *bw;
> > + bool input;
> > + int i;
> > +
> > + if (kstrtobool(buf, &input))
> > + return -EINVAL;
> > +
> > + new_wi_state = kzalloc(struct_size(new_wi_state, iw_table, nr_node_ids),
> > + GFP_KERNEL);
> > + if (!new_wi_state)
> > + return -ENOMEM;
> > + for (i = 0; i < nr_node_ids; i++)
> > + new_wi_state->iw_table[i] = 1;
> > +
> > + mutex_lock(&wi_state_lock);
> > + if (!input) {
>
> If input == old_wi_state->mode_auto, we can return directly?
Yes, that makes sense to me.
> > static void wi_cleanup(void) {
> > + sysfs_remove_file(&wi_group->wi_kobj, &wi_group->auto_kobj_attr.attr);
>
> Why not just
>
> sysfs_remove_file(&wi_group->wi_kobj, &wi_auto_attr.attr);
>
> ?
Also makes sense!!
> ---
> Best Regards,
> Huang, Ying
Thank you for your great feedback Ying, I'll make changes based on
your suggestions and shortly send up a v9. I hope you have a great day!
Joshua
next prev parent reply other threads:[~2025-05-10 18:51 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-05 18:23 Joshua Hahn
2025-05-10 5:25 ` Huang, Ying
2025-05-10 18:51 ` Joshua Hahn [this message]
2025-05-11 2:58 ` Joshua Hahn
2025-05-11 12:56 ` Honggyu Kim
2025-05-12 14:14 ` Joshua Hahn
2025-05-16 4:37 ` Honggyu Kim
2025-05-16 14:43 ` Joshua Hahn
2025-05-17 8:26 ` Huang, Ying
2025-05-12 1:35 ` Huang, Ying
2025-05-12 14:25 ` Joshua Hahn
2025-05-12 22:29 ` Andrew Morton
2025-05-13 14:01 ` Joshua Hahn
2025-05-13 1:41 ` Huang, Ying
2025-05-13 13:59 ` Joshua Hahn
2025-05-19 1:56 ` Joshua Hahn
2025-05-19 22:31 ` Andrew Morton
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=20250510185150.4078843-1-joshua.hahnjy@gmail.com \
--to=joshua.hahnjy@gmail.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=gourry@gourry.net \
--cc=gregkh@linuxfoundation.org \
--cc=hannes@cmpxchg.org \
--cc=honggyu.kim@sk.com \
--cc=horen.chuang@linux.dev \
--cc=kernel-team@meta.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=osalvador@suse.de \
--cc=rafael@kernel.org \
--cc=ying.huang@linux.alibaba.com \
--cc=yunjeong.mun@sk.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox