From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from gentwo.org (gentwo.org [62.72.0.81]) (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 0999F3E5A2B for ; Wed, 22 Jul 2026 18:06:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=62.72.0.81 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784743606; cv=none; b=sw1Mf8qOn94ypu/YSWbPvwTPoEqY4C8njbMyr1MYUUeR9Y2OKmFrSMyx1zNoxoAFiaQTNbj2E3WzprHhpQXTeVKxUuwsNkA2cgLtiPiG2FSoTpM5lJLp+gGjHMOBMfv+ifisj7+VN13F3BmlqBX6YGCQqyONIW5dcaUHtdJH0lI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784743606; c=relaxed/simple; bh=IhJ6HrjbX9ulWZ31b/VI3aihrkVfoaAR7YJscyo1M/g=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=mH04zRD4vk7ih/yC7pf4Ki1GoJ2sbNnbST70XD3vrDJIGdMnUHi5vFhFz73tthj/DYpdti2P7FfzWI9Ky0PrVB/qiQCArXB4skrinPE0p5WcVpUtZ+lKLfQZc1/q1Lusj5VWyWaEvOIRSWnyo0RHsDjgl+tYIcNwUu/1OcyI8pQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=gentwo.org; spf=pass smtp.mailfrom=gentwo.org; dkim=pass (1024-bit key) header.d=gentwo.org header.i=@gentwo.org header.b=UTZYJ4/3; arc=none smtp.client-ip=62.72.0.81 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=gentwo.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gentwo.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=gentwo.org header.i=@gentwo.org header.b="UTZYJ4/3" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gentwo.org; s=default; t=1784743602; bh=IhJ6HrjbX9ulWZ31b/VI3aihrkVfoaAR7YJscyo1M/g=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=UTZYJ4/3+T3xx8JsoNFqm7ln4jic1MTDNoC9dfliMxC5IPIHb5tUA8i/HBqysjuJA q+u6VE6L/81ycdkqgP7rpr9PydFDi4p73lZeAsWCGIQua3gXX1sTKAIV6HZwTrb3iT 1O77ceYV/9YqX/YMt7PIxoKJDN8eb0Rr+50svpjg= Received: by gentwo.org (Postfix, from userid 1007) id 4D570402BC; Wed, 22 Jul 2026 11:06:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gentwo.org (Postfix) with ESMTP id 4BA62401E1; Wed, 22 Jul 2026 11:06:42 -0700 (PDT) Date: Wed, 22 Jul 2026 11:06:42 -0700 (PDT) From: Shubhang To: Christian Loehle cc: Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , K Prateek Nayak , "Christoph Lameter (Ampere)" , Shubhang Kaushik , linux-kernel@vger.kernel.org Subject: Re: [PATCH] sched/fair: Prefer waker CPU for reciprocal sync wakeups In-Reply-To: <2aadc9bb-43d8-403d-a5ec-321c0f428026@arm.com> Message-ID: <82b8ff02-a7c8-e9d0-1d6d-3628819089f7@gentwo.org> References: <20260721-b4-sched-sync-wakeup-v1-1-dc94f184e27f@gentwo.org> <2aadc9bb-43d8-403d-a5ec-321c0f428026@arm.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; format=flowed Hi Christian, Thanks for the review. On Wed, 22 Jul 2026, Christian Loehle wrote: > On 7/22/26 01:04, Shubhang Kaushik (Ampere) wrote: >> Pipe and futex ping-pong workloads can be dominated by handoff cost. In >> such cases, placing the wakee on an idle CPU can be slower than keeping >> the pair on the same runqueue. >> >> Use the existing last_wakee and wake_wide() state to identify narrow >> reciprocal WF_SYNC wakeups: >> >> A wakes B >> B wakes A >> A wakes B >> ... > > But the futex ping-pong doesn't set WF_SYNC in the first place or am I missing > something? Yes, the futex runs were only regression checks here. I'll drop the futex wording from the description and keep the motivation to pipe sync handoffs. >> @@ -9548,6 +9570,7 @@ select_task_rq_fair(struct task_struct *p, int prev_cpu, int wake_flags) >> int cpu = smp_processor_id(); >> int new_cpu = prev_cpu; >> int want_affine = 0; >> + int wide = 0; >> /* SD_flags and WF_flags share the first nibble */ >> int sd_flag = wake_flags & 0xF; >> >> @@ -9557,6 +9580,7 @@ select_task_rq_fair(struct task_struct *p, int prev_cpu, int wake_flags) >> lockdep_assert_held(&p->pi_lock); >> if (wake_flags & WF_TTWU) { >> record_wakee(p); >> + wide = wake_wide(p); >> >> if ((wake_flags & WF_CURRENT_CPU) && >> cpumask_test_cpu(cpu, p->cpus_ptr)) >> @@ -9569,7 +9593,12 @@ select_task_rq_fair(struct task_struct *p, int prev_cpu, int wake_flags) >> new_cpu = prev_cpu; >> } >> >> - want_affine = !wake_wide(p) && cpumask_test_cpu(cpu, p->cpus_ptr); >> + if (sync && !wide && >> + READ_ONCE(p->last_wakee) == current && >> + prefer_sync_pair_cpu(p, cpu)) >> + return cpu; > > This must move further below (to check for SD_WAKE_AFFINE) otherwise it ignores isolcpus. Agreed. The early return bypasses the existing SD_WAKE_AFFINE check, including the isolcpus handling that comes through the sched-domain setup. I'll move it into the wake-affine block so it only applies after that check. Regards, Shubhang Kaushik