From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5870EC4332F for ; Wed, 8 Nov 2023 12:44:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344504AbjKHMoT (ORCPT ); Wed, 8 Nov 2023 07:44:19 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36492 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344373AbjKHMoS (ORCPT ); Wed, 8 Nov 2023 07:44:18 -0500 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 794F01BF0 for ; Wed, 8 Nov 2023 04:44:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; 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=knxggHqPTlhd43d7Uw7Cyj/GXM5IL414IJsbF/Ox+MU=; b=gNX0r/2K22CNvAtxv8dRtl8Rw/ /l2p7m0dg74Z77KdUFK4cpfpWd1rZW2cgVh4bHLYFT63I832kyeJ8SQoqDRgNHen/+wRB6o4T4BPL QXA0pjkv3f/tsRYcK7QSbQssSvaJPAV+asXxbUovcC1P/11nhWGt0EzhCO7w2qd5AZHiX5y8L8uCi cIPgBzsZtzQHOkB20AERxsp5gPbCsuy+spABhNOiHZTd1gJ+nMTxicThnpv6Cl8E8H+ziQwSP20bQ 8pco5ZScLxtNEpV5LJEi2pl4nunkrLcTDokW9OUwlGcTEiRJWXx4Mw/TabUA5VrFjsVZnZOMP0v3Y W7jrgtUA==; Received: from j130084.upc-j.chello.nl ([24.132.130.84] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1r0hua-0013dY-UB; Wed, 08 Nov 2023 12:44:01 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 4A0C730049D; Wed, 8 Nov 2023 13:44:01 +0100 (CET) Date: Wed, 8 Nov 2023 13:44:01 +0100 From: Peter Zijlstra To: Daniel Bristot de Oliveira Cc: Daniel Bristot de Oliveira , Steven Rostedt , Joel Fernandes , Ingo Molnar , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Ben Segall , Mel Gorman , Valentin Schneider , linux-kernel@vger.kernel.org, Luca Abeni , Tommaso Cucinotta , Thomas Gleixner , Vineeth Pillai , Shuah Khan , Phil Auld Subject: Re: [PATCH v5 6/7] sched/deadline: Deferrable dl server Message-ID: <20231108124401.GQ8262@noisy.programming.kicks-ass.net> References: <20231107114732.5dd350ec@gandalf.local.home> <7d1ea71b-5218-4ee0-bc89-f02ee6bd5154@redhat.com> <3e58fad7-7f66-4e48-adcc-0fda9e9d0d07@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3e58fad7-7f66-4e48-adcc-0fda9e9d0d07@kernel.org> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 07, 2023 at 07:50:28PM +0100, Daniel Bristot de Oliveira wrote: > > The code is not doing what I intended because I thought it was doing overload > > control on the replenishment, but it is not (my bad). > > > > I am still testing but... it is missing something like this (famous last words). > > diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c > index 1092ca8892e0..6e2d21c47a04 100644 > --- a/kernel/sched/deadline.c > +++ b/kernel/sched/deadline.c > @@ -842,6 +842,8 @@ static inline void setup_new_dl_entity(struct sched_dl_entity *dl_se) > * runtime, or it just underestimated it during sched_setattr(). > */ > static int start_dl_timer(struct sched_dl_entity *dl_se); > +static bool dl_entity_overflow(struct sched_dl_entity *dl_se, u64 t); > + > static void replenish_dl_entity(struct sched_dl_entity *dl_se) > { > struct dl_rq *dl_rq = dl_rq_of_se(dl_se); > @@ -852,9 +854,18 @@ static void replenish_dl_entity(struct sched_dl_entity *dl_se) > /* > * This could be the case for a !-dl task that is boosted. > * Just go with full inherited parameters. > + * > + * Or, it could be the case of a zerolax reservation that > + * was not able to consume its runtime in background and > + * reached this point with current u > U. > + * > + * In both cases, set a new period. > */ > - if (dl_se->dl_deadline == 0) > - replenish_dl_new_period(dl_se, rq); > + if (dl_se->dl_deadline == 0 || > + (dl_se->dl_zerolax_armed && dl_entity_overflow(dl_se, rq_clock(rq)))) { > + dl_se->deadline = rq_clock(rq) + pi_of(dl_se)->dl_deadline; > + dl_se->runtime = pi_of(dl_se)->dl_runtime; > + } > > if (dl_se->dl_yielded && dl_se->runtime > 0) > dl_se->runtime = 0; Should we rather not cap the runtime, something like so? Because the above also causes period drift, which we do not want. --- diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c index 58b542bf2893..1453a2cd0680 100644 --- a/kernel/sched/deadline.c +++ b/kernel/sched/deadline.c @@ -829,10 +829,12 @@ static inline void setup_new_dl_entity(struct sched_dl_entity *dl_se) */ static void replenish_dl_entity(struct sched_dl_entity *dl_se) { + struct sched_dl_entity *pi_se = pi_of(dl_se); struct dl_rq *dl_rq = dl_rq_of_se(dl_se); struct rq *rq = rq_of_dl_rq(dl_rq); + u64 dl_runtime = pi_se->dl_runtime; - WARN_ON_ONCE(pi_of(dl_se)->dl_runtime <= 0); + WARN_ON_ONCE(dl_runtime <= 0); /* * This could be the case for a !-dl task that is boosted. @@ -851,10 +853,13 @@ static void replenish_dl_entity(struct sched_dl_entity *dl_se) * arbitrary large. */ while (dl_se->runtime <= 0) { - dl_se->deadline += pi_of(dl_se)->dl_period; - dl_se->runtime += pi_of(dl_se)->dl_runtime; + dl_se->deadline += pi_se->dl_period; + dl_se->runtime += dl_runtime; } + if (dl_se->zerolax && dl_se->runtime > dl_runtime) + dl_se->runtime = dl_runtime; + /* * At this point, the deadline really should be "in * the future" with respect to rq->clock. If it's