From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f73.google.com (mail-wr1-f73.google.com [209.85.221.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D3315280A5A for ; Fri, 20 Mar 2026 09:18:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.73 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773998304; cv=none; b=WOWhbIwIO8wm6ddVG4B7O/rP3pVsI0RcknQSuYOl26NlyXqR0rewW5knzK26b+uWud8FKdyEGmBOgEs03wdCRZJKrXbjxLr1xMNoF46Tf/vXxfrrIEv8KgdhMTNH8/A+oQfU+7wH5rH5SdN5uj5Vk0k9Zqc4bpDkdrH85WMPM/w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773998304; c=relaxed/simple; bh=HINz8feOpsFhiodrZC++xNu2OiZ1aBWqnsN2/OzOSGw=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=M8fEu76oECNm6JI8TGHuBQDAj/kN1CPToVE8zX5oTCowGiRn6oG+eKl7qIXCgfz2BZg6b+grm6ZFi4xcNa/IDCi/SADjBluaG4TPi9fZx63F+pc4UEqsB8VblKfKAj0QL/8e/Rfa+qCrnQ392BOXvi4ActlmnsV53resBZp/oWs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--jpiecuch.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=av41EzO2; arc=none smtp.client-ip=209.85.221.73 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--jpiecuch.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="av41EzO2" Received: by mail-wr1-f73.google.com with SMTP id ffacd0b85a97d-43b53023d60so1081221f8f.2 for ; Fri, 20 Mar 2026 02:18:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1773998301; x=1774603101; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=YQdO70cAPWqKek1gtlbRcpkyz/EKyI3Kx/evAQw8zDs=; b=av41EzO2Cvs7K8/YgTp+AmilQmx7CjnSMKYEQ5igFhmRc+iQ9fVxMDee9Tn8cGO8Uo L2/KOCV2wgI24FlAOz/lc5Czv66HRRzScOj8XFHn1pMFVcwewgr+QSZ120sgZ7m/VL+8 SjDtKUPGt5DEv3zPkdfcllLArzLYHnhHQxzHVvmPIMsNfGOSsPwCfc+g5vNkAPyv1sf+ +Ez6GCv+M8PHTb4SJ+El738EW1f3at3iFJTyg0yvN6Nr+6GnxX+ckjt+KZ4qlEoFQsG6 YzOEHRNRYh+Ttqo6Mz+6Ot7P1WpyhqYqS0uI909nQpuYOpMV5yRLl20fVXVvxf0y+ly7 L8Gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773998301; x=1774603101; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=YQdO70cAPWqKek1gtlbRcpkyz/EKyI3Kx/evAQw8zDs=; b=SQ4M60PCLykBdzXiWrgi5OsazaIzWCFoU48o0J+b/M4pdzhG03sPQv9cjjzwoAyWm7 Ro+yovon6H0wKhJQWwByvWT77f5Ki5xAr4tzoX6jcF0sRvXUqpG/2o02LGbWoAVixSEK RSAKLlM905otOETGhf+nv20lltCZJOfKC4rmHgcwodXhmXO2QF1pfVh+eDabuZ3yjjox OOlKIwWQqGFK8A/740MNpVIxm9iRbQq4BoQdj10GZci/r1jjGmt8dNKnr/ixJyvR9Hj6 fFp+wfyZ6H+ioqvkF2hR/4aTattPhlXL8T2q3JMe3eAFQD6NRxZSKCFVMAEJIEI+On9/ mQeA== X-Forwarded-Encrypted: i=1; AJvYcCW6La3etD2a2Nmurty7Xnm2VeCEal30O6n0eMzsAvmh7b/5YGQ/ebUiaZaNlsAV4AlT9wjneTMlvXPbzFY=@vger.kernel.org X-Gm-Message-State: AOJu0Yz+btngvEBB6iQNZBbfI/td0Ds+++83uHItXU9Ek3fOL7Tj73W5 K+HfzXWVJlSrv1/WoosyTCwAPR74ou3moDNwZj6VpPLDACUu3iw6974nxitgLzRDot9qDKrqYKT ct0eOcusnzqc6Dw== X-Received: from wmjt15.prod.google.com ([2002:a7b:c3cf:0:b0:487:c1:68c5]) (user=jpiecuch job=prod-delivery.src-stubby-dispatcher) by 2002:a05:600c:3d97:b0:486:fa35:aef2 with SMTP id 5b1f17b1804b1-486febb5989mr33327835e9.4.1773998301204; Fri, 20 Mar 2026 02:18:21 -0700 (PDT) Date: Fri, 20 Mar 2026 09:18:20 +0000 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260319083518.94673-1-arighi@nvidia.com> X-Mailer: aerc 0.21.0-0-g5549850facc2 Message-ID: Subject: Re: [PATCH v2 sched_ext/for-7.1] sched_ext: Invalidate dispatch decisions on CPU affinity changes From: Kuba Piecuch To: Andrea Righi , Kuba Piecuch Cc: Tejun Heo , David Vernet , Changwoo Min , Emil Tsalapatis , Christian Loehle , Daniel Hodges , , Content-Type: text/plain; charset="UTF-8" On Thu Mar 19, 2026 at 9:09 PM UTC, Andrea Righi wrote: > On Thu, Mar 19, 2026 at 10:31:30AM +0000, Kuba Piecuch wrote: >> On Thu Mar 19, 2026 at 8:35 AM UTC, Andrea Righi wrote: >> > @@ -2537,9 +2546,26 @@ static void dispatch_to_local_dsq(struct scx_sched *sch, struct rq *rq, >> > } >> > >> > if (src_rq != dst_rq && >> > - unlikely(!task_can_run_on_remote_rq(sch, p, dst_rq, true))) { >> > - dispatch_enqueue(sch, rq, find_global_dsq(sch, task_cpu(p)), p, >> > - enq_flags | SCX_ENQ_CLEAR_OPSS | SCX_ENQ_GDSQ_FALLBACK); >> > + unlikely(!task_can_run_on_remote_rq(sch, p, dst_rq, false))) { >> > + /* >> > + * Affinity changed after dispatch decision and the task >> > + * can't run anymore on the destination rq. >> >> More of a nitpick, but this doesn't necessarily mean that the affinity changed. >> The scheduler could have also issued an invalid dispatch to a CPU outside of >> the task's cpumask (e.g. due to a bug), in which case the task won't be >> re-enqueued if we simply drop the dispatch, correct? > > That's right, the scheduler could have issues an invalid dispatch and in > that case we would just drop the task on the floor, which is not really > nice, it'd be better to immediately error in this case. And we don't need > the global DSQ fallback, since we're erroring anyway. > > I need to rethink this part... The fundamental problem here is differentiating between buggy dispatches that should have never been issued and dispatches that were valid at the moment the BPF scheduler was preparing the task for dispatch, but became invalid due to racing cpumask changes. The crucial observation is that SCX will only detect racing dequeues/enqueues if they race with the window between scx_bpf_dsq_insert() and finish_dispatch(). That's because scx_bpf_dsq_insert() stores a snapshot of the task's current qseq value, which is compared in finish_dispatch(). The BPF-side cpumask checks traditionally happen outside of this window, making finish_dispatch() incapable of detecting cpumask changes that raced with the BPF-side check but happened strictly before scx_bpf_dsq_insert(). To resolve this, we need to extend the race detection window so that it includes the BPF-side checks. The simple way to do this is to do scx_bpf_dsq_insert() at the very beginning, once we know which task we would like to dispatch, and cancel the pending dispatch via scx_bpf_dispatch_cancel() if any of the pre-dispatch checks fail on the BPF side. This way, the "critical section" includes BPF-side checks, and SCX will ignore the dispatch if there was a dequeue/enqueue racing with the critical section. With this solution, we can throw an error if task_can_run_on_remote_rq() is false, because we know that there was no racing cpumask change (if there was, it would have been caught earlier, in finish_dispatch()).