linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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


  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