From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) (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 84B62312825 for ; Tue, 11 Aug 2026 05:41:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.163.158.5 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786426864; cv=none; b=C/EBS29Uu5cqsk4s4ZYHYb9hZmE/BcteSnRHbtqXRTOclwSZjpvpS6wZDjWMrEHFEWdYrRYFXOfkQNmgxC22ENUjyXQL2tOd6aBIbnBsO6zXPtQajJ+WzG3+wSkeFg/iihxJhyJSrghHD1OxRI9xHhFGA35IdJNoI6yHcKSkPhA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786426864; c=relaxed/simple; bh=Fx5+8IuInFDzdsrprK980O8IAKGKz/gq83ynSetv78g=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=bve54Ax4bdfpc67L2hyUVpXCAWainq458VsesPli/+/gaOH1qyaZZq8YYxgKpoIKIiOk1wRzbXZNjlJxXoOsNsxKB6A2I6xYg4+wMc0MURe9bjFt+Frs5jrcXEWfH2YKre7l8Q/+pdSjen7qlxyWPMp4A0CSvcp68AIT6kvrtyQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.ibm.com; spf=pass smtp.mailfrom=linux.ibm.com; dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b=nf6nIhrY; arc=none smtp.client-ip=148.163.158.5 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.ibm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.ibm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b="nf6nIhrY" Received: from pps.filterd (m0356516.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 67AN1jDk2878948; Tue, 11 Aug 2026 05:40:37 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=pp1; bh=PvwTGZ fJ98a46fYUE73KqUmUbzKOm+9jsbKDgBMnmIg=; b=nf6nIhrYcBQ8PMIcFagRP8 lm2CK2OWH6TIxS/PmbEfltLlREwQZHHHfG18y5PBy6If7Ya2iGGbaRDwlePL/RAB 3A/7c4mwY+jGBTWhxeq6/VCv0ltIHmcP2frze1e9KmRs+AF5EyH4+qCWPyPuZ76U a+Z8qxiXQ6xO1s0naqsGcY6rp50UWaxBb7i54MbI4l0AxrRKqQzug4Arp63Kx+52 VZykykG0WxCH6xlhP40ovSzs2d7ufxq6CEU39t8W5+ePXPnC6puxOHDeYEJzHRe5 6+EuxqefaWa5eFauJ1+IxYCo+zvq08ZWHmwbBdURlnPKcJnolUJR8KR76VsntTWQ == Received: from ppma11.dal12v.mail.ibm.com (db.9e.1632.ip4.static.sl-reverse.com [50.22.158.219]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4fwvp2twdg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 11 Aug 2026 05:40:36 +0000 (GMT) Received: from pps.filterd (ppma11.dal12v.mail.ibm.com [127.0.0.1]) by ppma11.dal12v.mail.ibm.com (8.18.1.7/8.18.1.7) with ESMTP id 67B5QJwj017111; Tue, 11 Aug 2026 05:40:35 GMT Received: from smtprelay06.wdc07v.mail.ibm.com ([172.16.1.73]) by ppma11.dal12v.mail.ibm.com (PPS) with ESMTPS id 4fxhfxygqs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 11 Aug 2026 05:40:35 +0000 (GMT) Received: from smtpav02.dal12v.mail.ibm.com (smtpav02.dal12v.mail.ibm.com [10.241.53.101]) by smtprelay06.wdc07v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 67B5eYd632178802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 11 Aug 2026 05:40:34 GMT Received: from smtpav02.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6025758065; Tue, 11 Aug 2026 05:40:34 +0000 (GMT) Received: from smtpav02.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3185E5805E; Tue, 11 Aug 2026 05:40:29 +0000 (GMT) Received: from [9.123.5.43] (unknown [9.123.5.43]) by smtpav02.dal12v.mail.ibm.com (Postfix) with ESMTP; Tue, 11 Aug 2026 05:40:28 +0000 (GMT) Message-ID: Date: Tue, 11 Aug 2026 11:10:27 +0530 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] sched/fair: Let sync wakeups target the waker's core To: Chen Yu 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, Madadi Vineeth Reddy 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> Content-Language: en-US From: Madadi Vineeth Reddy In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-Reinject: loops=2 maxloops=12 X-Authority-Analysis: v=2.4 cv=AMtp2X5w c=1 sm=1 tr=0 ts=6a7ab5d4 cx=c_pps a=aDMHemPKRhS1OARIsFnwRA==:117 a=aDMHemPKRhS1OARIsFnwRA==:17 a=IkcTkHD0fZMA:10 a=Sv0fKeRqtYgA:10 a=VkNPw1HP01LnGYTKEx00:22 a=RnoormkPH1_aCDwRdu11:22 a=Y2IxJ9c9Rs8Kov3niI8_:22 a=Fp4w5Xdd9Y7wvJjrYDAA:9 a=QEXdDO2ut3YA:10 X-Proofpoint-GUID: z4o-b3IhBDD5IEo2Ba2ldEDl5jtdXa31 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODExMDA0NCBTYWx0ZWRfX/P2sE3iDidCm h0dCfW+1vAgvmQXgzr5IoM+B3t5yIHuIkjye/OQgdtkRUxhFnNoLJ2/19S4pec+XPpoXXDZu+hk CNbZo2SfTK6lx9kKGbLDaJNxjIh2XKllCRoIsL0azTwvfuHq1SnMNQ9PvRh0gVy8NKblS0ZWdmt 8x/dUmHjqFnYKmKterlPe+rKIuNRexnajzH3IX1yOjVhjYRIZbODJM+ijBhnN+D6EkJSXgYd28V NCitIuvY3nsLXXIOFWpkmty8ujOvN1COQKxWuOj1IU0hEiYLl60jaiMU9d9YShwOUGV92074p98 fdVgBkwiiVIr2a+GZ5hIHiwAAnsFTIkYcLxlQRhIA11WA0v7WPfiBAmm92yCcBw92kVi+dM3NEe btQfBUb+DpazMZiKH0yF2ufeR+g+NJ+IMXeftxfMWSz+FqSpmMx/OiURPSLmMM87iJUTSab7GOA YLcSoPnfphPjuUDjx3Q== X-Proofpoint-ORIG-GUID: gYThIJgq13QZRFxbwHOJQeB3fgoSkuMP X-Proofpoint-Spam-Info: AW1haW4tMjYwODExMDA0NCBTYWx0ZWRfX2vpqd1afMj/r ehh03ZLRcvgR/Or0azMK5leJ505+cxI5jQOhVoGyN4eSyWL0wdy9MzT/DI66DeMJYdqa55/FFyr Z9Q4OnB58HS9+69/xKoFgXPfmXDMw70= X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-08-10_06,2026-08-10_03,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 adultscore=0 lowpriorityscore=0 clxscore=1011 priorityscore=1501 impostorscore=0 phishscore=0 spamscore=0 bulkscore=0 malwarescore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2608110044 Hi Chen Yu, On 06/08/26 19:52, Chen Yu wrote: > 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. Correct. > > 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? > Thanks for pointing this out. In the softirq case current is an arbitrary interrupted task that resumes as soon as the softirq returns. I will add in_task() in v2. > > ======================================================================================= > 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)); Both wake_affine() branches bias towards waker's cpu on sync. target becomes waker's CPU and select_idle_sibling() then searches the waker's sd_llc. So the hint directs the search domain rather than a specific CPU is my understanding. Thanks, Vineeth > ====================================================================================== > > thanks, > Chenyu