From: Jianyong Wu <wujianyong@hygon.cn>
To: Ethan Zhao <etzhao1900@gmail.com>
Cc: "jianyong.wu@outlook.com" <jianyong.wu@outlook.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH] sched/fair: fix task_numa_migrate to consider both task and group benefits
Date: Fri, 5 Sep 2025 02:14:30 +0000 [thread overview]
Message-ID: <4c57fcd55047412b9752aeba79f86dec@hygon.cn> (raw)
In-Reply-To: <72d087b8-1af1-44a6-88c4-04a9ff98f660@gmail.com>
Hello Ethan,
Thanks for reply.
There is inconsistency between the comments and the code. See the discussion in an older patch here https://lkml.org/lkml/2015/6/16/540
Following that, the issue is with the comments, not the code.
Bests
Jianyong
> -----Original Message-----
> From: Ethan Zhao <etzhao1900@gmail.com>
> Sent: Friday, September 5, 2025 9:13 AM
> To: Jianyong Wu <wujianyong@hygon.cn>
> Cc: jianyong.wu@outlook.com; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] sched/fair: fix task_numa_migrate to consider both task
> and group benefits
>
>
>
> On 8/29/2025 4:55 PM, Jianyong Wu wrote:
> > The comment indicates that when searching for a suitable NUMA node, we
> > should ensure that the selected node benefits both the task and its
> > NUMA group. However, the current implementation can only guarantee
> > that either the task or the group benefits, but not necessarily both.
> >
> > Signed-off-by: Jianyong Wu <wujianyong@hygon.cn>
> > ---
> > kernel/sched/fair.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index
> > b173a059315c..58c899738399 100644
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -2568,7 +2568,7 @@ static int task_numa_migrate(struct task_struct
> *p)
> > /* Only consider nodes where both task and groups benefit
> */
> > taskimp = task_weight(p, nid, dist) - taskweight;
> > groupimp = group_weight(p, nid, dist) - groupweight;
> > - if (taskimp < 0 && groupimp < 0)
> > + if (taskimp < 0 || groupimp < 0)
> Perhaps you misunderstand the comment, && means either the task or the
> group has NO benefit from this migration, it wouldn't be done.
> But if you replace it with ||, you will ignore the target node that could benefit
> either the task or the group.
>
> There is more logic to consider the benefit for both task & group in the later
> function part.
>
> One question, why not
> if (taskimp <= 0 && groupimp <= 0) ?
>
> Thanks,
> Ethan
> > continue;
> >
> > env.dist = dist;
>
next prev parent reply other threads:[~2025-09-05 2:14 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-29 8:55 [PATCH] sched/fair: fix task_numa_migrate to consider both task and group benefits Jianyong Wu
2025-09-05 1:12 ` Ethan Zhao
2025-09-05 2:14 ` Jianyong Wu [this message]
2025-09-05 3:01 ` Ethan Zhao
-- strict thread matches above, loose matches on Subject: below --
2025-08-29 8:57 Jianyong Wu
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=4c57fcd55047412b9752aeba79f86dec@hygon.cn \
--to=wujianyong@hygon.cn \
--cc=etzhao1900@gmail.com \
--cc=jianyong.wu@outlook.com \
--cc=linux-kernel@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).