From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f73.google.com (mail-wm1-f73.google.com [209.85.128.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 41077368294 for ; Fri, 19 Jun 2026 13:12:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.73 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781874748; cv=none; b=LVtHgmiA7Gu5m+dbmNBhcZUbyhNrngNIl3DxQUBxb1Sr+ihehMXoXtlNJGZNi30UojrbL09pEelmshPRAvE5MEpfySpqoyTnpH3u8Hx1dwasrcE7B5egARXHSXTYHYhrCsyNAhgcVwuue3tra4azSXhD+7V9B9G7A8cS5H5q6+s= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781874748; c=relaxed/simple; bh=tI8FWr4t1Tam40JsvYQNIz8kDX58QRx2y73o7JnaLJY=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=l36LUlOT+bZS79aEunsi/u35tlwXwkc9agbLxJjfH/sjK6sQPrpFrz68DOoRgpK6tiU9XHkwWEOyZlW78anvR6/bMnc4ZsL0UmzSAdpKSgAcz7xGsCPs1I2/RzeCPS/bKuMeMC1J9gLHj56RMR+t9S/R35WvPqbIb9xJii0y/sU= 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=EKw6QrVn; arc=none smtp.client-ip=209.85.128.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="EKw6QrVn" Received: by mail-wm1-f73.google.com with SMTP id 5b1f17b1804b1-490b37e1f47so14522365e9.0 for ; Fri, 19 Jun 2026 06:12:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1781874745; x=1782479545; 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=6wwPOWK2IcIFVS6cg4NCDP0w8aIO3Ri3aHh6++DWsQ4=; b=EKw6QrVn9AhD2Den4tPtJXFMkRWZ291z1lFPMwJ4AWc8otzAH7+hy3J4vMX2Hue0pO vKmqUAmP8RxKv+4Sqv7rsPS7NMVR3frbEDsheDHNi8miDj1mSEAWEUyzZSYM/BlZRWX2 EhqaDn5c8c/kcCoYRMj5wGZ2I71OaH2QR6XcMIlq1lEWJoVOU1ej6MD1TgBxq9oT1rCM julRECtRIYoiTITBdQ5lMprQvvGPHXb6gncLeMdoOK/E5ULatJGnBmmpCzh6vXhgy7cg Ow78+wqCFahu2jJ/ffhqJCPI9uQ17/B6muJcLNmvbZZA2m1MAMFWLu+nChSzDWo+75kB FFrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781874745; x=1782479545; 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=6wwPOWK2IcIFVS6cg4NCDP0w8aIO3Ri3aHh6++DWsQ4=; b=FdBJzgKXMNXZM8ruWFJPQBDQlRVaervRTPqNf7C2vy8XzABXiqaKnzMwh1MmoeM/qj PubsCir7lIPb9PSKEnUaiAyWzZUMx2cqPtZ1CcB4g1/esR9eTMI+65/DblLKdISZreQ7 7iFcQMhSO+ucLBUGio5KvTd/2sOmhLeQXh9SGZOV9inASRupwmKQLFY+xjbz4hrAoleV 9MMmkA20KFjAdad22DlQqho4uZOhz7bvwAQxldd5zGh1jQmlda1JKa5cV6WWeCqmBofn O9hehjrn9oHSZsmhcOfPg1dvD+6R3nWkeIXc3Tr0bZjCEwxvv0DFotyxyBY4BPbwi+Lk 2GEA== X-Forwarded-Encrypted: i=1; AFNElJ8oKXBOfmTJSgAEKtrwE2LPSKfU3UAIHUL8OxV4QfCocujEEZ+tFZGF/+aGmqqS8aUVfpWyZVKCoPbDmYM=@vger.kernel.org X-Gm-Message-State: AOJu0Yyr9im6Bc49zMdtD2M2UukClHG1qLdu/yYFE7kilY5150wH6QtY 2dMutceoZZthtgF8UZA+/eMmzHVG0ewT1IvE0Zrs0gvQHxzWAWpyuwJd70l3ADIIrMPzXRx/oYO rInu4bBVSd9eoDg== X-Received: from wmbjq12.prod.google.com ([2002:a05:600c:55cc:b0:487:2186:fcf7]) (user=jpiecuch job=prod-delivery.src-stubby-dispatcher) by 2002:a05:600c:6d89:b0:490:e196:e8aa with SMTP id 5b1f17b1804b1-4923f582bb4mr49573435e9.28.1781874744344; Fri, 19 Jun 2026 06:12:24 -0700 (PDT) Date: Fri, 19 Jun 2026 13:12:23 +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: <20260618170047.283701-1-jpiecuch@google.com> X-Mailer: aerc 0.21.0-0-g5549850facc2 Message-ID: Subject: Re: [PATCH sched_ext/for-7.2] sched_ext: check remote rq eligibility under task's rq lock From: Kuba Piecuch To: Andrea Righi , Kuba Piecuch Cc: Tejun Heo , Changwoo Min , David Vernet , , Content-Type: text/plain; charset="UTF-8" Hi Andrea, Thank you for the review! On Fri Jun 19, 2026 at 7:31 AM UTC, Andrea Righi wrote: > Looks good to me, but we should also update the "Cross-CPU Task Migration" doc > in kernel/sched/ext_internal.h to be consistent with this change (see below if > it makes sense to you). > > With that: > > Reviewed-by: Andrea Righi > > Thanks, > -Andrea > > kernel/sched/ext_internal.h | 16 +++++++++------- > 1 file changed, 9 insertions(+), 7 deletions(-) > > diff --git a/kernel/sched/ext_internal.h b/kernel/sched/ext_internal.h > index b76633c52c96a..b63d80ae21157 100644 > --- a/kernel/sched/ext_internal.h > +++ b/kernel/sched/ext_internal.h > @@ -1471,18 +1471,20 @@ static const char *scx_enable_state_str[] = { > * The sched_ext core uses a "lock dancing" protocol coordinated by > * p->scx.holding_cpu. When moving a task to a different rq: > * > - * 1. Verify task can be moved (CPU affinity, migration_disabled, etc.) > - * 2. Set p->scx.holding_cpu to the current CPU > - * 3. Set task state to %SCX_OPSS_NONE; dequeue waits while DISPATCHING > + * 1. Set p->scx.holding_cpu to the current CPU > + * 2. Set task state to %SCX_OPSS_NONE; dequeue waits while DISPATCHING > * is set, so clearing DISPATCHING first prevents the circular wait > * (safe to lock the rq we need) > - * 4. Unlock the current CPU's rq > - * 5. Lock src_rq (where the task currently lives) > - * 6. Verify p->scx.holding_cpu == current CPU, if not, dequeue won the > + * 3. Unlock the current CPU's rq > + * 4. Lock src_rq (where the task currently lives) > + * 5. Verify p->scx.holding_cpu == current CPU, if not, dequeue won the > * race (dequeue clears holding_cpu to -1 when it takes the task), in > * this case migration is aborted > - * 7. If src_rq == dst_rq: clear holding_cpu and enqueue directly > + * 6. If src_rq == dst_rq: clear holding_cpu and enqueue directly > * into dst_rq's local DSQ (no lock swap needed) > + * 7. Otherwise, verify under src_rq that the task can be moved to dst_rq > + * (CPU affinity, migration_disabled, etc.). If not, clear holding_cpu > + * and enqueue the task on the fallback DSQ on src_rq. > * 8. Otherwise: call move_remote_task_to_local_dsq(), which releases > * src_rq, locks dst_rq, and performs the deactivate/activate > * migration cycle (dst_rq is held on return) > Absolutely, will send a v2 shortly that includes the documentation change. Thanks, Kuba