From nobody Thu Apr 9 14:54:56 2026 Received: from mail-pf1-f174.google.com (mail-pf1-f174.google.com [209.85.210.174]) (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 368EA38F254 for ; Mon, 2 Mar 2026 10:12:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.174 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772446363; cv=none; b=bM78UQ0F2FQctCZK+4IQqtglDSHLQeg/WrJ/udFBMpowkgfmYLbyen+jMXIE626+HFHjTI8jZ9haOT7lNlLJmvUZ46jwu4p08xQRo47L+sh3j+RLEIjuW350Nwmfx1OZROFTz1n2+F/LQqwofrO3b2klVKzjJV2MqCpGXuuXkbw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772446363; c=relaxed/simple; bh=25w8kVK/3TwPBHT5ewVR2fOpPkFv00z7JbsVtRCRrOM=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=ICrghiN6BpCa1To5MxFvvrIwfuRXeYhMpFz2ZTEPNZtIi8tOIDvnzt7qiXLEL0iJP6NoXrQuFW4umg5Hu1MxFtj4c+miejtj/kkdGB15gujDpj3Qa7nBBt6YXzCnP7wYVEQMo0bWmfBRL6SRGEzekRVma4ZAmjMXvb0qvWyQ21A= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=THtj393i; arc=none smtp.client-ip=209.85.210.174 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="THtj393i" Received: by mail-pf1-f174.google.com with SMTP id d2e1a72fcca58-824a3509a12so1917519b3a.2 for ; Mon, 02 Mar 2026 02:12:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772446361; x=1773051161; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=tdD8wHjOi6O9RcPY1mVqc/dyICyjVBQpoUPu/IJ6x0Y=; b=THtj393iCgoz9/+/8uxw3EBeMX1VTsOkb7iXRShlTDOap3x7Kp6Me+jrbW5WZDLzB5 HyaOADHFekzwLtHif+zJQCxpp3TWK3ctO2o3lDrF2uinFILCZl8dAKGlvlVJCDc2xgFg qm6cmUxlueVXIc7BY0+JrYPEIhJHKg70dBzIEtf2CLZ46T2Q/0yJrn5IVY4e5UPSldBC Z6f5zFUweM2sreGAnWqlLQdvE38DgeivhwXvC9+tOg/mvzuvT5iNtpP3W3UUB+5cfTo/ gkC1RTQP92Fk5WUmA5nncFGKfrr18Re/eUD5OLVsTKQiuCOCeJ9pKv28sStMi9w8zdsJ xxcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772446361; x=1773051161; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=tdD8wHjOi6O9RcPY1mVqc/dyICyjVBQpoUPu/IJ6x0Y=; b=Y8Bm9aKrPf8l8vuax2LL18wHHxuOrs5qVt0eQ1bqryiGZ7fCotTdr75KPfSu59Djjc kBvyUwb7d9bFkMNfBYaoP4+U1JZuRWX2RTwtR06VOyucpKElwOsJAGovSijkSXQJqoxg 54Dg+jJQHu/vffibqIz5lPYTJlzApIh4vseACh+PnhkM8VpFfwCgc549Iosa8URdmOVo zpsA5qnPrwGP19vIYkvDeKGXi/7Ue9wBmKDhHJ9/NL5mZXbDtT3sHHehnwTV26h9CaWh IjJh2vNula2+iXcQjWUV6WAjoZlKF9umCgLyU7/pF3k0j83ywNj/AL0XdNqEBBGiIJZf KYUg== X-Gm-Message-State: AOJu0YxbajtKmAaW6yW8qZG3FcCccDSUXth7HMvvfcVcdh1lGtst7ikh MDrCSQ3+mlQvbFUaHrr0nTjcbZnOkQFLTewKOeT7H8enB4pfbbDV6HSiH6x6RY6W X-Gm-Gg: ATEYQzyjvZY6wI/jQXFX3SfQD1xSaSQiRFwr9J/M4UOajP5KXIu67z9DFSFX1L88Lgp TQV+uCx+srSJc5SbEslZqia2PHLoJ8BWHnLwjn//NOqg+XscPnNcOq+yJ1a2ramQUZyB1S9p1L7 oCeStb1zMdxcPoRQvxzlVclHedobZcQFGstuzbcRFApRMstwPgY+T/7ha0kZR4lRCJjdBC3Vq9u VJpwQoJtaBP54OAJGqj09WIsoomtPeFptTF3aieG569bFV5ZOCptKxSi8kxErJcxxzQh80BhCqb GWXYRfzvf0OTnybsSy7VPTxMjCqA/LWUwucSn8CV4ynmtSBGkxt3YYEYNEbZOpLBmHpN2Fkn8+b FAQsKytQdhl3WR2tfPdRUeNbr0+xSNfkddrPH78v/bjKy6AT4WcTfJ5x92Ljcp7k2RYi8aVT5il iLCkw0dLVnsXd2VzskJzpCC7I0UEjIAFnhIuhPa3qX2HN9OB6FSs6K4CjFVh/oAnRRUFbdFEZJt ulA X-Received: by 2002:a05:6a21:3988:b0:38e:90ca:5a4a with SMTP id adf61e73a8af0-395c39f7bdcmr12078999637.1.1772446361437; Mon, 02 Mar 2026 02:12:41 -0800 (PST) Received: from mi-HP-ProDesk-680-G6-PCI-Microtower-PC.mioffice.cn ([43.224.245.226]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-c70fa84e602sm10965305a12.32.2026.03.02.02.12.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Mar 2026 02:12:41 -0800 (PST) From: soolaugust@gmail.com To: linux-kernel@vger.kernel.org Cc: Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , zhidao su Subject: [PATCH] sched/proxy_exec: Handle sched_delayed owner in find_proxy_task() Date: Mon, 2 Mar 2026 18:12:35 +0800 Message-ID: <20260302101235.3988601-1-soolaugust@gmail.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: zhidao su The blocked-owner check at the top of the inner loop unconditionally lumps two distinct states into one: 1. !on_rq -- the owner has fully left the runqueue; PE cannot proceed and proxy_deactivate() is the right action. 2. sched_delayed -- EEVDF deferred-dequeue: the owner called schedule() but was kept physically in the RB-tree because its lag was still positive (entity_eligible() =3D=3D true= ). Case 2 is transient. The owner will resolve to one of two outcomes: * A wakeup arrives --> sched_delayed cleared, on_rq stays 1, owner eligible for PE on the next cycle. * Dequeue completes --> on_rq drops to 0, caught by case 1 above. Calling proxy_deactivate() in case 2 is unnecessarily aggressive: it removes the high-priority donor from the runqueue and clears its blocked_on, discarding valid PE state for a single missed cycle. A task that enters the mutex slowpath sets blocked_on before calling schedule(), and try_to_block_task() is only reached via the explicit DEQUEUE_DELAYED path -- not the sched_delayed shortcut. Therefore a sched_delayed owner never has blocked_on set and the chain cannot be followed further regardless. Split the check: keep proxy_deactivate() for !on_rq, and switch to proxy_resched_idle() for sched_delayed. This mirrors the existing handling of task_on_rq_migrating() owners (see proxy_resched_idle() call below), which also uses a yield-to-idle to handle a transient per-owner condition without disturbing the donor. Signed-off-by: zhidao su --- kernel/sched/core.c | 25 +++++++++++++++++++++++-- 1 file changed, 23 insertions(+), 2 deletions(-) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index b7f77c165a6..dc9f17b35e4 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -6625,10 +6625,31 @@ find_proxy_task(struct rq *rq, struct task_struct *= donor, struct rq_flags *rf) return p; } =20 - if (!READ_ONCE(owner->on_rq) || owner->se.sched_delayed) { - /* XXX Don't handle blocked owners/delayed dequeue yet */ + if (!READ_ONCE(owner->on_rq)) { + /* + * Owner is off the runqueue; proxy execution cannot + * proceed through it. Deactivate the donor so it will + * be properly re-enqueued when the owner eventually + * wakes and releases the mutex. + */ return proxy_deactivate(rq, donor); } + if (owner->se.sched_delayed) { + /* + * The owner is in EEVDF's deferred-dequeue state: it + * called schedule() but the scheduler kept it physically + * on the runqueue because its lag was still positive. + * This is a transient condition -- the owner will either + * be woken (clearing sched_delayed) or fully dequeued + * (clearing on_rq) very shortly. + * + * Unlike the !on_rq case the donor is still valid; do + * not deactivate it. Yield to idle so the owner can + * complete its state transition, then retry PE on the + * next scheduling cycle. + */ + return proxy_resched_idle(rq); + } =20 if (task_cpu(owner) !=3D this_cpu) { /* XXX Don't handle migrations yet */ --=20 2.43.0