From nobody Sun Jun 14 14:29:40 2026 Received: from mail-pf1-f177.google.com (mail-pf1-f177.google.com [209.85.210.177]) (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 DBF202C21E8 for ; Fri, 3 Apr 2026 08:12:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.177 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775203942; cv=none; b=Kza+NpA74to+YZKjERqCtyipVTGXLg1ed2kJGybdewRvNhhOonxa7n/rv6Oj2uIUiJm0RHcPNUxvT6c6eeLOZGenH+qyVoTQzhY1G9hQTPDbgJ1SNuQlitGoccKRpcB1h/jEuGFtoCshhLbbt5aV6EfEMmZS5uVw2vorUJL8ps4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775203942; c=relaxed/simple; bh=Y9CjayZjEjmi1fjtmx5242qwulvyuaEyu+Qr7zdnHGw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=mbR6uoasQQ2Orb6X7w3YiO2FzRkHwJu90dZKRi6KYxRRjH4F1DhM+2422WeDjAzT4MNzp04oo9AIliNe9iN1LaX6C9weQeWU+6/byjMSW7s5P3YNXM+0LXPaZEDdF5GT9vqPDkPXno9Sw0FnORXEEgOaHaIkxSenC/Y7QU8MFGk= 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=ayeYk+n3; arc=none smtp.client-ip=209.85.210.177 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="ayeYk+n3" Received: by mail-pf1-f177.google.com with SMTP id d2e1a72fcca58-82c68339cf0so1684819b3a.0 for ; Fri, 03 Apr 2026 01:12:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1775203940; x=1775808740; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=qkmtlBqJyeMhmf/fpyrVm6bQ25AjXSfu5bLYx1pIcXc=; b=ayeYk+n32fgUDAa3pghLO95J7Ua8E0m6wFUS8uOUNfH9tvLjdy1St1c+MwnyAGGi8R +xgQTCWaVqEfAzST8LJgVRSQzkPATOSoKGu89idKLQ5EdOjdfyndL7ZtmZy2bI4Q0FfU PoT5pDQ8gx5ehNR5fIwqRFNUr/om5KfV4T3FZnLPP5BZQoaYH8iZ0FdouHqAg0w2Uj4t nMuYSQKXEKaxzximDSs+/g74xadS3OGdBaY8bYale+3C/pFA8rgd9XuGFdjxEU/PqKwS MiQrnEbSuyWRk2zO7l0Rr0qR/5bpvaOGw7HPZMAe69FVVcbVMfdqdQwlUKEbUgLsbxHX Yq4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775203940; x=1775808740; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=qkmtlBqJyeMhmf/fpyrVm6bQ25AjXSfu5bLYx1pIcXc=; b=mH2gghoV9zMfeT5KvRxkcQItgMvtf+09N/hdibetnrcZychvJi/Us+T6Q+SAF61LYi K+K/+ZNjPIt1j+stjtaCehLpdhbYoA8fXO4IcY28WmUQZa1vfFmhd+TrWOzQsN5pcmCm UFoqGumtAS8jXflp781Idk2ZUEq12QzLVL4rIEnX+dnXxwi0ngJMi7r4y+Oe+N3nhfdL aNtunJhqq6+YRmWceEZKZZSsM9Uc47JdgaP/IXXN6W3ZumzVjHDLLfZVqJb5zF5qN4cR HdVeTW52k0Vj3XQEWADYJiIMpyieRFBcYhPmQ/viF2h7q3FStQkG6b1oJkv9WNK2FTkQ r2xw== X-Forwarded-Encrypted: i=1; AJvYcCVjQQgBZYVn/2Iu4seReOLG2XhrED5RZbQx+/qGyxrG0YLM3OcFHYBziPsdLdRplvEmk6nfmWQYpLVqHqQ=@vger.kernel.org X-Gm-Message-State: AOJu0YzNsxUtg4QfIkPqEqSiw836jA+N2uFAfeM2UP3QO2bsMTvJgq+J tImLhePVFqtOAsWMDVZlSXHKAxJIVtNyxPFdrKivdgfnBpBWpeVl9n6v X-Gm-Gg: ATEYQzx9prhHK7Vv75xZ/BLZ+9805nk3j/f0kjER6INaFZeP2ZWW8S3a0rHLSq23TsK B9J7AiQPJzwsoukrPQPTq5qtZLJMEZb+DjBuS5XNsgE+1KZzXOMqBICoqQgiYfyldJ6N7ywrqoV foBRFSrraf+D3oXULGdw4pBHQjksAr34cFQhJj667a7RtZW17GVHBXteiwka6fOyMEPq02On36A +aQ/xX+1F66gUgeGQajlNnMPtmaPjmn6lo7LyFCN/2I4JtvEjdQADfqHKO1EaSOCfRd1P7OK/2+ XmDB5F09j5ZnlX2RIWfXhvQC5tAZ6ddPY4AcCg9lLGOVY57vLZSVrhYt1LktH6xlKLR2FGZFi1Q MF/tDgkfvABklzDckngYX59sXosidBcYIxVeUay3IPWUJ+U3GxRlPjF6iSApdFAE2iS1Z8BURRP KWFLj7yafWIQ2Gik0VVQQpgzY6Md2+Xfqmfyp/qTOEXamMSafk5M5/pAlFrL/wB0ChcF0ryhDqP lxchLy/OvjAqNk= X-Received: by 2002:a05:6a20:7d8b:b0:39e:fc1d:868c with SMTP id adf61e73a8af0-39f2dada9acmr2062451637.26.1775203940008; Fri, 03 Apr 2026 01:12:20 -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-82cf9c6b80dsm6531276b3a.42.2026.04.03.01.12.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Apr 2026 01:12:19 -0700 (PDT) From: soolaugust@gmail.com To: jstultz@google.com, juri.lelli@redhat.com Cc: peterz@infradead.org, mingo@redhat.com, linux-kernel@vger.kernel.org, zhidao su Subject: [PATCH] sched/deadline: Fix stale dl_defer_running in update_dl_entity() if-branch Date: Fri, 3 Apr 2026 16:12:15 +0800 Message-ID: <20260403081215.3942454-1-soolaugust@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: References: 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 commit 115135422562 ("sched/deadline: Fix 'stuck' dl_server") added a dl_defer_running =3D 0 reset in the if-branch of update_dl_entity() to handle the case where [4] D->A is followed by [1] A->B (lapsed deadline). The intent was to ensure the server re-enters the zero-laxity wait when restarted after the deadline has passed. With Proxy Execution (PE), RT tasks proxied through the scheduler appear to trigger frequent dl_server_start() calls with expired deadlines. When this happens with dl_defer_running=3D1 (from a prior starvation episode), Peter's fix forces the fair_server back through the ~950ms zero-laxity wait each time. In our testing (virtme-ng, 4 CPUs, 4G RAM, ksched_football): With this fix: ~1s for all players to check in Without this fix: ~28s for all players to check in The issue appears to be that the clearing in update_dl_entity()'s if-branch is too aggressive for the PE use case. replenish_dl_new_period() already handles this via its internal guard: if (dl_se->dl_defer && !dl_se->dl_defer_running) { dl_se->dl_throttled =3D 1; dl_se->dl_defer_armed =3D 1; } When dl_defer_running=3D1 (starvation previously confirmed by the zero-laxity timer), replenish_dl_new_period() skips arming the zero-laxity timer, allowing the server to run directly. This seems correct: once starvation has been confirmed, subsequent start/stop cycles triggered by PE should not re-introduce the deferral delay. Note: this is the same change as the HACK revert in John's PE series (679ede58445 "HACK: Revert 'sched/deadline: Fix stuck dl_server'"), but with the rationale documented. The state machine comment is updated to reflect the actual behavior of replenish_dl_new_period() when dl_defer_running=3D1. Signed-off-by: zhidao su Acked-by: Juri Lelli Reported-by: John Stultz Tested-by: John Stultz --- kernel/sched/deadline.c | 12 +++--------- 1 file changed, 3 insertions(+), 9 deletions(-) diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c index 01754d699f0..30b03021fce 100644 --- a/kernel/sched/deadline.c +++ b/kernel/sched/deadline.c @@ -1034,12 +1034,6 @@ 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) { /* @@ -1662,11 +1656,11 @@ void dl_server_update(struct sched_dl_entity *dl_se= , s64 delta_exec) * enqueue_dl_entity() * update_dl_entity(WAKEUP) * if (dl_time_before() || dl_entity_overflow()) - * dl_defer_running =3D 0; * replenish_dl_new_period(); * // fwd period - * dl_throttled =3D 1; - * dl_defer_armed =3D 1; + * if (!dl_defer_running) + * dl_throttled =3D 1; + * dl_defer_armed =3D 1; * if (!dl_defer_running) * dl_defer_armed =3D 1; * dl_throttled =3D 1; --=20 2.43.0