From nobody Sun Jun 14 11:25:42 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 6FADD2BF3F3 for ; Thu, 2 Apr 2026 13:30:57 +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=1775136658; cv=none; b=gUbpP8Laij8NBHuIUnV0ezTg5ReAMM0PXDMOS+ts38T4VBhLDAOfd7UPJTiYcHui+fMcW/SOO6prOJrFoirq8pxhreMPPp1MCzVJHQdyNvLJxUId2OweK5rRyUN44lK2Omisl+6uusCTTffGYGkvMa0yGvWlpGVq8knJ1f2RScM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775136658; c=relaxed/simple; bh=jMhJfxVmUKZ7zeEyXBtiUtCVZkW+8itMOOk5lO4t+n8=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=tuRS8ANyGYZoZHgx6tVM+yfYGtjenJOhWAtTCUvzWdXDZ/JzTCWv8CtxBDNE8ldhvzvUKdwLmGUq5Us76EJIHUr4gse7eUmmjsi/PIACwnDutkTjAB409N5NRZH74Pqd68HBRUS2P/eUqMZj/bPlUsImvDn4Wexic9GeqnGZwGA= 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=hCCfut16; 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="hCCfut16" Received: by mail-pf1-f174.google.com with SMTP id d2e1a72fcca58-82ce09b4197so386993b3a.2 for ; Thu, 02 Apr 2026 06:30:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1775136657; x=1775741457; 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=29a5ObgHBiPYl3Gbvf7vgEAi4QzC6p0OHxxgYCSMR5k=; b=hCCfut16z9INKGv9zUPwUypu0IfmbUVvqGwWSPQzgMnPsE11Si1YUVQo0YzYv4yiR6 iw1VQ2aaVefs+4cgTgYNvmxhpNDnTdthW55unKoqkhrl2QU8+Kv9TR3sPS+dYYcqD6em Qs6HMdQ4vswDIpo2ATVn+7XhYYi+1gNLejGTrbtqYc+0QjN8wX4j2PYOaicyToxubE5G UwbCIE/XFRmxnS3PTXW75jKTeHroxVN58is4sit8jZohi6TDkWpX1OSWJlwMOddcwQnz O07VDVQD5ATC32753liJMemKEbInr6vjUb2VgQ99lYBoC2IQ86N1gfM+ItfsY6LCf4Xg jemw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775136657; x=1775741457; 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=29a5ObgHBiPYl3Gbvf7vgEAi4QzC6p0OHxxgYCSMR5k=; b=ER2BvMkJUK2IiRDR+5jQyypHCijfAIWMvr3I2gh6LLnbVVAzYKqc2FImllvognAPDq TA7TiQE5uojJnr7aikNRKc/BN9i2f3S2ekUGerw/F6HRrZe/xBoly+n6SCZXxBymvAw/ ZZ6srOOWlmJc6ezldqp36Sao8ZYx6gvTrb7+QweTBZzSjOOfn0BA3Q9Mjv4yVtmkvdEq +zYKgX443IxvUq4ILNcsWOGDlHoEwc/cT8uHTYdnv0toFIBlst+UMfjC2JSPqebgji6J njenvEx1AAdAJHuMECptjqDThPfzlKGM1fC5BhFQ59yKHYLXOhCat9/XUV3siemA9SUU wlPQ== X-Forwarded-Encrypted: i=1; AJvYcCVyI5g0SKnPHecEk7n7yTELKQYdV42MW5sg/Qjvyb/9AxBrnQefnA0/v5/hG+fbVxR+LFbR5lDp5Q7VjlE=@vger.kernel.org X-Gm-Message-State: AOJu0Ywks/rzZReacnS0yYvcYIPvzbdRDWpLbgZNDzZNl8IJhQTpCfXc +KQ/fqnWkFfjsVc1MODn1FUqqzqGhrb09PH1Pbum767bNJf2jwHYnxJV X-Gm-Gg: ATEYQzyhfHzlzmuhmpBLSWDGIrvIpqwHB1HLhrg4SzJ581OOIZEYuGSz635WZabLETD xvfNYRO52yMJXZmotKPICgg7B1miwb5sHVhlGw1nGk9Tqwxb/aT3i8PlVjCwydy1RzD3yiEaC/f J7Gxu1O/OBEj0/jdq9ZVKqFBsHvF/DKvvCsWr0o0jya0zbvMoQQSVh5tsUY4AJpRBOHC+NUFM7f EVb8RT8uy6wEto8W/zScDuU99GcRRBKb5QZmKgQb+34JCK76IbD2MRkjRFk5GN428fzg1kAvyKg mPqsIwfzN6Jr8kqGheZZIQBbfcg9/j+vuQqxwsio3wYhEh7typduaLl4mUZfTA1IGoiwNcgyOeT U9Xk2+w0Teq2h8XTReGNRY8B1h7efFl9yC8H5UjJ/VyHpBszqflC2/hkluFk9nQUmhy3dFKnPfj E+5R+dloq5C3oXLc2OC9i+MODHcqaarRs1bHaBzodR7ZzI12zE2YLUY0UFcMICNaOzquPucjK35 LuR X-Received: by 2002:a05:6a00:b904:b0:7fb:f87d:a0aa with SMTP id d2e1a72fcca58-82ce8b46f4dmr7681086b3a.52.1775136656624; Thu, 02 Apr 2026 06:30:56 -0700 (PDT) Received: from mi-HP-ProDesk-680-G6-PCI-Microtower-PC.mioffice.cn ([43.224.245.226]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-82cf9b27313sm3052593b3a.5.2026.04.02.06.30.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Apr 2026 06:30:56 -0700 (PDT) From: soolaugust@gmail.com To: jstultz@google.com, bristot@redhat.com Cc: peterz@infradead.org, mingo@redhat.com, linux-kernel@vger.kernel.org, arighi@nvidia.com, Zhidao Su Subject: [PATCH] sched/deadline: Fix stale dl_defer_running in dl_server else-branch Date: Thu, 2 Apr 2026 21:30:50 +0800 Message-ID: <20260402133050.607777-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 Peter's fix (115135422562) cleared dl_defer_running in the if-branch of update_dl_entity() (deadline expired/overflow). This ensures replenish_dl_new_period() always arms the zero-laxity timer. However, with PROXY_WAKING, re-activation hits the else-branch (same-period, deadline not expired), where dl_defer_running from a prior starvation episode can be stale. During PROXY_WAKING CPU return-migration, proxy_force_return() migrates the task to a new CPU via deactivate_task()+attach_one_task(). The enqueue path on the new CPU triggers enqueue_task_fair() which calls dl_server_start() for the fair_server. Crucially, this re-activation does NOT call dl_server_stop() first, so dl_defer_running retains its prior value. If a prior starvation episode left dl_defer_running=3D1, and the server is re-activated within the same period: [4] D->A: dl_server_stop() clears flags but may be skipped when dl_server_active=3D0 (server was already stopped before return-migration triggered dl_server_start()) [1] A->B: dl_server_start() -> enqueue_dl_entity(WAKEUP) -> update_dl_entity() enters else-branch -> 'if (!dl_defer_running)' guard fires, skips dl_defer_armed=3D1 / dl_throttled=3D1 -> server enqueued into [D] state directly -> update_curr_dl_se() consumes runtime -> start_dl_timer() with dl_defer_armed=3D0 (slow path) -> boot time increases ~72% Fix: in the else-branch, unconditionally clear dl_defer_running and always set dl_defer_armed=3D1 / dl_throttled=3D1. This ensures every same-period re-activation properly re-arms the zero-laxity timer, regardless of whether a prior starvation episode had set dl_defer_running. The if-branch (deadline expired) is left untouched: replenish_dl_new_period() contains its own guard ('if (!dl_defer_running)') that arms the zero-laxity timer only when dl_defer_running=3D0. With PROXY_WAKING, dl_defer_running=3D1 in the deadline-expired path means a genuine starvation episode is ongoing, so the server can skip the zero-laxity wait and enter [D] directly. Clearing dl_defer_running here (as Peter's fix did) forces every PROXY_WAKING deadline-expired re-activation through the ~950ms zero-laxity wait. Measured boot time to first ksched_football event (4 CPUs, 4G): This fix: ~15-20s Without fix (stale dl_defer_running): ~43-62s (+72-200%) Note: Andrea Righi's v2 patch addresses the same symptom by clearing dl_defer_running in dl_server_stop(). However, dl_server_stop() is not called during PROXY_WAKING return-migration (proxy_force_return() calls dl_server_start() directly without dl_server_stop()). This fix targets the correct location: the else-branch of update_dl_entity(). Signed-off-by: Zhidao Su --- kernel/sched/deadline.c | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c index 01754d699f0..b2bcd34f3ea 100644 --- a/kernel/sched/deadline.c +++ b/kernel/sched/deadline.c @@ -1034,22 +1034,22 @@ static void update_dl_entity(struct sched_dl_entity= *dl_se) return; } =20 - /* - * When [4] D->A is followed by [1] A->B, dl_defer_running - * needs to be cleared, otherwise it will fail to properly - * start the zero-laxity timer. - */ - dl_se->dl_defer_running =3D 0; replenish_dl_new_period(dl_se, rq); } else if (dl_server(dl_se) && dl_se->dl_defer) { /* - * The server can still use its previous deadline, so check if - * it left the dl_defer_running state. + * The server can still use its previous deadline. Clear + * dl_defer_running unconditionally: a stale dl_defer_running=3D1 + * from a prior starvation episode (set in dl_server_timer() when + * the zero-laxity timer fires) must not carry over to the next + * activation. PROXY_WAKING return-migration (proxy_force_return) + * re-activates the server via attach_one_task()->enqueue_task_fair() + * without calling dl_server_stop() first, so the flag is not + * cleared in the [4] D->A path for that case. + * Always re-arm the zero-laxity timer on each re-activation. */ - if (!dl_se->dl_defer_running) { - dl_se->dl_defer_armed =3D 1; - dl_se->dl_throttled =3D 1; - } + dl_se->dl_defer_running =3D 0; + dl_se->dl_defer_armed =3D 1; + dl_se->dl_throttled =3D 1; } } =20 --=20 2.43.0