From: Joshua Hahn <joshua.hahnjy@gmail.com>
To: Rakie Kim <rakie.kim@sk.com>
Cc: gourry@gourry.net, akpm@linux-foundation.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, linux-cxl@vger.kernel.org,
joshua.hahnjy@gmail.com, dan.j.williams@intel.com,
ying.huang@linux.alibaba.com, kernel_team@skhynix.com,
honggyu.kim@sk.com, yunjeong.mun@sk.com
Subject: Re: [PATCH 2/4] mm/mempolicy: Enable sysfs support for memory hotplug in weighted interleave
Date: Fri, 7 Mar 2025 10:19:59 -0800 [thread overview]
Message-ID: <20250307182015.489780-1-joshua.hahnjy@gmail.com> (raw)
In-Reply-To: <20250307063534.540-3-rakie.kim@sk.com>
On Fri, 7 Mar 2025 15:35:31 +0900 Rakie Kim <rakie.kim@sk.com> wrote:
Hi Rakie, thank you for your work on this patch! I think it makes a lot of
sense, given the discussion between Gregory & Honggyu in the weighted
interleave auto-tuning patch.
I have a few small nits and questions that I wanted to raise, but none that
should change the behavior at all : -)
> Previously, sysfs entries for weighted interleave were only created during
> initialization, preventing dynamically added memory nodes from being recognized.
>
> This patch enables sysfs registration for nodes added via memory hotplug,
> allowing weighted interleave settings to be updated as the system memory
> configuration changes.
>
> Signed-off-by: Rakie Kim <rakie.kim@sk.com>
> ---
> mm/mempolicy.c | 51 +++++++++++++++++++++++++++++++-------------------
> 1 file changed, 32 insertions(+), 19 deletions(-)
>
> diff --git a/mm/mempolicy.c b/mm/mempolicy.c
> index 385607179ebd..fc10a9a4be86 100644
> --- a/mm/mempolicy.c
> +++ b/mm/mempolicy.c
> @@ -3389,6 +3389,13 @@ struct iw_node_attr {
> int nid;
> };
>
> +struct iw_node_group {
> + struct kobject *wi_kobj;
> + struct iw_node_attr **nattrs;
> +};
> +
> +static struct iw_node_group *ngrp;
> +
> static ssize_t node_show(struct kobject *kobj, struct kobj_attribute *attr,
> char *buf)
> {
> @@ -3431,8 +3438,6 @@ static ssize_t node_store(struct kobject *kobj, struct kobj_attribute *attr,
> return count;
> }
>
> -static struct iw_node_attr **node_attrs;
> -
> static void sysfs_wi_node_release(struct iw_node_attr *node_attr,
> struct kobject *parent)
> {
> @@ -3448,7 +3453,7 @@ static void sysfs_wi_release(struct kobject *wi_kobj)
> int i;
>
> for (i = 0; i < nr_node_ids; i++)
> - sysfs_wi_node_release(node_attrs[i], wi_kobj);
> + sysfs_wi_node_release(ngrp->nattrs[i], wi_kobj);
Nit: I think it is slightly awkward to have a global struct ngrp, and then have
its members passed individually like this. Of course there's nothing that
we can do for sysfs_wi_release's argument, but I think we can make the
arguments for sysfs_wi_node_release a bit cleaner. An idea would just be to
pass an integer (nid) instead of the nattrs[i] pointer. We also don't need
to pass wi_kobj, since it is accessible from within sysfs_wi_node_release.
Once we make both these changes, patch 3 becomes a little bit cleaner (IMHO),
where we acquire the lock for the ngrp struct, then access its contents,
and we don't have to pass two pointers as arguments when they are already
accessible via the global struct anyways.
> kobject_put(wi_kobj);
> }
>
> @@ -3486,12 +3491,10 @@ static int add_weight_node(int nid, struct kobject *wi_kobj)
> return -ENOMEM;
> }
>
> - node_attrs[nid] = node_attr;
> + ngrp->nattrs[nid] = node_attr;
> return 0;
> }
>
> -struct kobject *wi_kobj;
> -
> static int wi_node_notifier(struct notifier_block *nb,
> unsigned long action, void *data)
> {
> @@ -3504,10 +3507,10 @@ static int wi_node_notifier(struct notifier_block *nb,
>
> switch(action) {
> case MEM_ONLINE:
> - err = add_weight_node(nid, wi_kobj);
> + err = add_weight_node(nid, ngrp->wi_kobj);
Same idea here, we probably don't need to pass wi_kobj into add_weight_node.
With that said, I can also see the argument for passing the struct itself,
since it saves a line of variable declaration & definition.
[...snip...]
Please let me know what you think! I hope you have a great day, thank you
again for this patch!
Joshua
Sent using hkml (https://github.com/sjp38/hackermail)
next prev parent reply other threads:[~2025-03-07 18:20 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-07 6:35 [PATCH 0/4] mm/mempolicy: Add memory hotplug support " Rakie Kim
2025-03-07 6:35 ` [PATCH 1/4] mm/mempolicy: Support memory hotplug " Rakie Kim
2025-03-07 6:35 ` [PATCH 2/4] mm/mempolicy: Enable sysfs support for " Rakie Kim
2025-03-07 18:19 ` Joshua Hahn [this message]
2025-03-10 8:28 ` Rakie Kim
2025-03-07 6:35 ` [PATCH 3/4] mm/mempolicy: Fix duplicate node addition in sysfs for " Rakie Kim
2025-03-07 6:35 ` [PATCH 4/4] mm/mempolicy: Fix memory leaks in mempolicy_sysfs_init() Rakie Kim
2025-03-07 15:23 ` Gregory Price
2025-03-10 8:23 ` Rakie Kim
2025-03-07 15:56 ` [PATCH 0/4] mm/mempolicy: Add memory hotplug support in weighted interleave Gregory Price
2025-03-07 21:55 ` Gregory Price
2025-03-10 9:03 ` Rakie Kim
2025-03-10 14:13 ` Gregory Price
2025-03-12 8:18 ` Rakie Kim
2025-03-10 9:03 ` Rakie Kim
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=20250307182015.489780-1-joshua.hahnjy@gmail.com \
--to=joshua.hahnjy@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=dan.j.williams@intel.com \
--cc=gourry@gourry.net \
--cc=honggyu.kim@sk.com \
--cc=kernel_team@skhynix.com \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rakie.kim@sk.com \
--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