All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chen Yu <chen.yu@linux.dev>
To: Madadi Vineeth Reddy <vineethr@linux.ibm.com>
Cc: K Prateek Nayak <kprateek.nayak@amd.com>,
	Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Juri Lelli <juri.lelli@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
	Valentin Schneider <vschneid@redhat.com>,
	Chen Yu <yu.c.chen@intel.com>, Tim Chen <tim.c.chen@intel.com>,
	Vinicius Costa Gomes <vinicius.gomes@intel.com>,
	linux-kernel@vger.kernel.org, sh@gentwo.org
Subject: Re: [PATCH] sched/fair: Let sync wakeups target the waker's core
Date: Thu, 6 Aug 2026 22:22:32 +0800	[thread overview]
Message-ID: <anSYqNz4ZRRuTwZZ@three-body> (raw)
In-Reply-To: <93b0d4fa-f161-4a27-8234-9fd9aea2ac50@linux.ibm.com>

Hi Madadi,

On Thu, Aug 06, 2026 at 10:20:38AM +0530, Madadi Vineeth Reddy wrote:

[ ... ]

> >> -static int select_idle_sibling(struct task_struct *p, int prev, int target)
> >> +static int select_idle_sibling(struct task_struct *p, int prev, int target, bool sync_core)
> >>  {
> >>  	bool has_idle_core = false;
> >>  	struct sched_domain *sd;
> >> @@ -9035,6 +9056,12 @@ static int select_idle_sibling(struct task_struct *p, int prev, int target)
> >>  			if ((unsigned int)i < nr_cpumask_bits)
> >>  				return i;
> >>  		}
> >> +
> >> +		if (sync_core) {
> >> +			i = select_idle_sync_core(p, sd, target);
> >> +			if ((unsigned int)i < nr_cpumask_bits)
> >> +				return i;
> >> +		}
> >>  	}
> >>  
> >>  	i = select_idle_cpu(p, sd, has_idle_core, target);
> >> @@ -9733,8 +9760,16 @@ select_task_rq_fair(struct task_struct *p, int prev_cpu, int wake_flags)
> >>  		return sched_balance_find_dst_cpu(sd, p, cpu, prev_cpu, sd_flag);
> >>  
> >>  	/* Fast path */
> >> -	if (wake_flags & WF_TTWU)
> >> -		return select_idle_sibling(p, prev_cpu, new_cpu);
> >> +	if (wake_flags & WF_TTWU) {
> >> +		bool sync_core = false;
> >> +		if (want_affine && sync && new_cpu == cpu) {
> >> +			struct rq *rq = cpu_rq(cpu);
> >> +
> >> +			sync_core = (rq->nr_running - cfs_h_nr_delayed(rq)) == 1;

If I understand correctly, the goal is to choose an idle SMT sibling as the waker
CPU, if:

1. the wakeup has WF_SYNC, and
2. the waker's SMT sibling CPUs are all idle, and
3. the waker is about to release the CPU.
In this way, we can "stack" the wakee on a core that is about to become idle to
get better cache locality.

Condition 3 above might not always hold true, because WF_SYNC is not restricted to
task context. softirq may also call wake_up_interruptible_sync_poll() with WF_SYNC,
and in that case, current is whatever task the softirq happened to interrupt.

Given that, would it be reasonable to add in_task() check to gate the softirq case?


=======================================================================================
BTW, in your git log:
"WF_SYNC tells the scheduler the waker is about to block ... when the waker's runqueue
holds a single runnable task it returns the waker's CPU, select_idle_sibling() then
discards that decision, because available_idle_cpu() is false for a CPU that is still
running the waker"

Thanks for this description. I realized that WF_SYNC is not what I previously thought:
stacking the wakee on the same CPU as the waker - that's not exactly right.
Now my understanding is that, WF_SYNC is actually asking the wakee to find an idle CPU
in the waker's LLC domain within select_idle_sibling(), humm, not sure if I missed anything:

sd = rcu_dereference_all(per_cpu(sd_llc, target));
======================================================================================

thanks,
Chenyu

  reply	other threads:[~2026-08-06 14:22 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-01  3:55 [PATCH] sched/fair: Let sync wakeups target the waker's core Madadi Vineeth Reddy
2026-08-01  6:43 ` Zhan Xusheng
2026-08-04  4:49 ` K Prateek Nayak
2026-08-04 12:13   ` Madadi Vineeth Reddy
2026-08-05  3:30     ` K Prateek Nayak
2026-08-06  4:50       ` Madadi Vineeth Reddy
2026-08-06 14:22         ` Chen Yu [this message]
2026-08-06 13:03 ` Kayra Cizmeci

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=anSYqNz4ZRRuTwZZ@three-body \
    --to=chen.yu@linux.dev \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=juri.lelli@redhat.com \
    --cc=kprateek.nayak@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=sh@gentwo.org \
    --cc=tim.c.chen@intel.com \
    --cc=vincent.guittot@linaro.org \
    --cc=vineethr@linux.ibm.com \
    --cc=vinicius.gomes@intel.com \
    --cc=vschneid@redhat.com \
    --cc=yu.c.chen@intel.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.