From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 818602C21D1 for ; Tue, 16 Sep 2025 11:02:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.92.199 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758020530; cv=none; b=dmZo4APA+GAQv0N4BNpnwo22+KUnyHtqXR0XANqumPGEV3MxSDX4+Ivdo0T48EUv7f8QPKpKwj3khcJN7ZQg6f9v5iwpOWkn0j97cm27uTQyeaZNMqMzA02G4Y7kbGWTbUnAd6xdaLnZj4soypN/v+KxOuLDHiHmAz3fxlsKE9E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758020530; c=relaxed/simple; bh=4cI5ZW1WfaF24KeilFyo5z+TYKNrwKYeXEur9FwYs1Y=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=m93+aSDRmEfRfkut9w1WtroKCdbXOxyUYK5jcN1jVpiR2A2t11MTAz4TX8n0N7MOEg5WVpLHSfJ3nM2icjltQroMzb/BjXFxl1I2DKIMg3hH6ron/QkmlaqQVqgGNjz6E5+dwVuJxsi4Vlx9lBNoJQuywjlJJYcm8ZdpPuL4zbw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=Ek7aoSLP; arc=none smtp.client-ip=90.155.92.199 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="Ek7aoSLP" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=iPNajYTtBdqRZTL01z1Fq1iRdOFQVIaiQjITIb2SjsU=; b=Ek7aoSLP8Fu7D5uIullr6yCzao mWtyNvrPDl/nNxHERlRltNT6UWgB4voUTSR3Z+CSpjX62ITOOLpwMKoi6YEriJExGXY6lZVaLthGn eXVDyIii3B3gC+OCraBukowYVamZpElsXIKF1DZFq78gqrG6FEiS3UAxJRoWoImBEd1ghTEEbRKAM rm0r1jtpbvsDm9lWH5UD0H7waeEsCgCQMP+XZkQDAbxo1Aatlq5K6fWH+Y2M81sdZIPBplYYGYCYM St1T7eDusrXwVgL/1TH/b8tqgWFbFnwv2RLpW4uTPmXjgcjpKK9JLmCpRAoC/t3Dq/R1GZJPCAT8v kveXddUw==; Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux)) id 1uyTRc-00000007BGF-0QHW; Tue, 16 Sep 2025 11:01:56 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 492D1300328; Tue, 16 Sep 2025 13:01:55 +0200 (CEST) Date: Tue, 16 Sep 2025 13:01:55 +0200 From: Peter Zijlstra To: Juri Lelli Cc: John Stultz , LKML , Ingo Molnar , Vincent Guittot , Dietmar Eggemann , Valentin Schneider , Steven Rostedt , Ben Segall , Mel Gorman , Xuewen Yan , K Prateek Nayak , Suleiman Souhlal , Qais Yousef , Joel Fernandes , kuyo chang , hupu , kernel-team@android.com Subject: Re: [RFC][PATCH] sched/deadline: Fix dl_server getting stuck, allowing cpu starvation Message-ID: <20250916110155.GH3245006@noisy.programming.kicks-ass.net> References: <20250916052904.937276-1-jstultz@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Tue, Sep 16, 2025 at 10:51:34AM +0200, Juri Lelli wrote: > > @@ -1173,7 +1171,7 @@ static enum hrtimer_restart dl_server_timer(struct hrtimer *timer, struct sched_ > > > > if (!dl_se->server_has_tasks(dl_se)) { > > replenish_dl_entity(dl_se); > > - dl_server_stopped(dl_se); > > + dl_server_stop(dl_se); > > return HRTIMER_NORESTART; > > } > > It looks OK for a quick testing I've done. Also, it seems to make sense > to me. The defer timer has fired (we are executing the callback). If the > server hasn't got tasks to serve we can just stop it (clearing the > flags) and wait for the next enqueue of fair to start it again still in > defer mode. hrtimer_try_to_cancel() is redundant (but harmless), > dequeue_dl_entity() I believe we need to call to deal with > task_non_contending(). > > Peter, what do you think? Well, the problem was that we were starting/stopping the thing too often, and the general idea of that commit: cccb45d7c4295 ("sched/deadline: Less agressive dl_server handling") was to not stop the server, unless it's not seen fair tasks for a whole period. Now, the case John trips seems to be that there were tasks, we ran tasks until budget exhausted, dequeued the server and did start_dl_timer(). Then the bandwidth timer fires at a point where there are no more fair tasks, replenish_dl_entity() gets called, which *should* set the 0-laxity timer, but doesn't -- because !server_has_tasks() -- and then nothing. So perhaps we should do something like the below. Simply continue as normal, until we do a whole cycle without having seen a task. diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c index 5b64bc621993..269ca2eb5ba9 100644 --- a/kernel/sched/deadline.c +++ b/kernel/sched/deadline.c @@ -875,7 +875,7 @@ static void replenish_dl_entity(struct sched_dl_entity *dl_se) */ if (dl_se->dl_defer && !dl_se->dl_defer_running && dl_time_before(rq_clock(dl_se->rq), dl_se->deadline - dl_se->runtime)) { - if (!is_dl_boosted(dl_se) && dl_se->server_has_tasks(dl_se)) { + if (!is_dl_boosted(dl_se)) { /* * Set dl_se->dl_defer_armed and dl_throttled variables to @@ -1171,12 +1171,6 @@ static enum hrtimer_restart dl_server_timer(struct hrtimer *timer, struct sched_ if (!dl_se->dl_runtime) return HRTIMER_NORESTART; - if (!dl_se->server_has_tasks(dl_se)) { - replenish_dl_entity(dl_se); - dl_server_stopped(dl_se); - return HRTIMER_NORESTART; - } - if (dl_se->dl_defer_armed) { /* * First check if the server could consume runtime in background. Notably, this removes all ->server_has_tasks() users, so if this works and is correct, we can completely remove that callback and simplify more. Hmm?