From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-173.mta0.migadu.com (out-173.mta0.migadu.com [91.218.175.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4AB513EF64A for ; Thu, 6 Aug 2026 14:22:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786026176; cv=none; b=gm17OgRXOXSafbrB3APGr2203YKu9Odo+lTxhvaJ9Yk7DydxC5tdzcyyur3/Dwid4HLSmcp61FGauOuyHk2Rw1+URt3u1QLHczf+VFzN6kqcvqOTSlHgrWr0w/Go70/XD3YLpsCNg6ohhJwBfgNTm9p1KJ44JQ8R758VUeNfCnY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786026176; c=relaxed/simple; bh=hgC/NUgsqtU6E/X3DEh8RNf2d0zVcNyKVS993AL4cmk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=SI0Zcpjes06WmKlGsF5mwUI7jAUezmlp+Nk9Tg/U6w9wGZcp9XPlNEH+lHGiNO96ObfQoXhAM3kIz8UcQnU8Z1nmwb1O8Dqs3DvJ3iY4NKjDFfbP7q6w9RAxCaxjzAGcRAliC76+Dnm6Vi4H2ZB7wRM3/QhVquZQoMjjyMGOJ8E= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=ENg5jXOW; arc=none smtp.client-ip=91.218.175.173 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="ENg5jXOW" Date: Thu, 6 Aug 2026 22:22:32 +0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1786026170; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=TivrkIyuuxQn+S+bztn+DgKNQF4JV8YnDIup/NcB1ME=; b=ENg5jXOWezOEs7LG4n9Nk7Jqs8CssmjZdpG150ElfzZO+HchLz1s1TnOFIlZTh1CJrCxO1 HvkJnnQ8m49kFM3qx+/LXLR2IIEZ6BUiKy3A875NEHuv1aeAkCT89pI10AA8DADxmDtRCC XvZWYO7qLmPCBTHvtrzytXQ7ro4zwRI= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Chen Yu To: Madadi Vineeth Reddy Cc: K Prateek Nayak , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , Chen Yu , Tim Chen , Vinicius Costa Gomes , linux-kernel@vger.kernel.org, sh@gentwo.org Subject: Re: [PATCH] sched/fair: Let sync wakeups target the waker's core Message-ID: References: <20260801035532.260625-1-vineethr@linux.ibm.com> <492e6bb3-504d-486a-ad9d-226e9d7235a3@amd.com> <40536fd1-cdc6-4fac-a78f-1ed0df1fcce6@linux.ibm.com> <93b0d4fa-f161-4a27-8234-9fd9aea2ac50@linux.ibm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <93b0d4fa-f161-4a27-8234-9fd9aea2ac50@linux.ibm.com> X-Migadu-Flow: FLOW_OUT 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