Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp142926pxu; Tue, 6 Oct 2020 02:53:19 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwOxMb+NzrF+ht7W0DzpgOD/ekp+RD8Kj8ZTrw6eQy33n0nzviqzxB0jBWGVbM3+HutCqqE X-Received: by 2002:a17:906:49cb:: with SMTP id w11mr4141796ejv.530.1601977999101; Tue, 06 Oct 2020 02:53:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601977999; cv=none; d=google.com; s=arc-20160816; b=ZsBCqNHbB06qCRRs4hrvBc95Zx+sVEXLhNdsqzki/62k4pSH7IyB6KLzlDPyfvqOxV ufd+WL3Q+C1wbbeuR1/RbCPuYmkiX0prW1uuRNjnF+wdQmargHlK5ARyiA1FW6EhdAa7 1bltpH3LQuovAiaJXc2HZsv5ZR9kMNeuAX0Xdyy975ynGkUC8jIWdbE1p+ldaBuvgDky pcgXmUqkbIOa1BdOfAXTaDTh5A2Sacdz395OyrinXajtyuuf5PuRM78nZiWYQRREuIi+ zD6uHvkuS+HumDTcEKgvVKPLsIz13qBoLOTKjLsfY5kDt4bn+WWzvbBU4+oAPuAG4nHu 2VmA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=5yuXfKQMovNfSwPWL09Gg3KLo9xMp/QtCSnYN+qoMxU=; b=t6AUL+OQnrmjMcObMXMSyhM7CbK+X8zOC7njDj19WlaU1rZk5uISdipK/s2CvqVxjU PWsO95yGb3vSoq+Gurw5jP1j1l/LfESI2JsINoupPik6HwX9vHIEHbny7QVcyvVaVN4p OGJQ8n7GellpidS3y8iOfIVoySETueOc8KnKVzQXmAIyrMp2ZkeTG8ZRHROc5YeG2Dog Z4CgJlM8YnxTmLVkqhMZYEnJUBu2R37nzF74iBCz2IaDsXuhOIkM2JqBq6li3J7ZL7Vu wDDdg93QPgQXUTjD5nXngPr3An77QcAXu3QOlqo+e0cphx9qpmxkNcBR6a3GO+XMaggp j+QQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t1si1671507ejb.712.2020.10.06.02.52.55; Tue, 06 Oct 2020 02:53:19 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726139AbgJFJvd (ORCPT + 99 others); Tue, 6 Oct 2020 05:51:33 -0400 Received: from ms01.santannapisa.it ([193.205.80.98]:63816 "EHLO mail.santannapisa.it" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725939AbgJFJvd (ORCPT ); Tue, 6 Oct 2020 05:51:33 -0400 Received: from [151.61.51.211] (account l.abeni@santannapisa.it HELO sweethome) by santannapisa.it (CommuniGate Pro SMTP 6.1.11) with ESMTPSA id 151709920; Tue, 06 Oct 2020 11:51:31 +0200 Date: Tue, 6 Oct 2020 11:51:26 +0200 From: luca abeni To: Juri Lelli Cc: peterz@infradead.org, mingo@redhat.com, rostedt@goodmis.org, tglx@linutronix.de, linux-kernel@vger.kernel.org, tommaso.cucinotta@santannapisa.it, alessio.balsini@gmail.com, bristot@redhat.com, dietmar.eggemann@arm.com, linux-rt-users@vger.kernel.org, mtosatti@redhat.com, williams@redhat.com, valentin.schneider@arm.com Subject: Re: [RFC PATCH v2 4/6] sched/deadline: Introduce deadline servers Message-ID: <20201006115126.453db362@sweethome> In-Reply-To: <20201006093523.GD4352@localhost.localdomain> References: <20200807095051.385985-1-juri.lelli@redhat.com> <20200807095051.385985-5-juri.lelli@redhat.com> <20201006095612.381d806f@sweethome> <20201006093523.GD4352@localhost.localdomain> X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 6 Oct 2020 11:35:23 +0200 Juri Lelli wrote: [...] > > > + if (dl_se->server_has_tasks(dl_se)) { > > > + enqueue_dl_entity(dl_se, dl_se, ENQUEUE_REPLENISH); > > > + resched_curr(rq); > > > + __push_dl_task(rq, &rf); > > > + } else { > > > + replenish_dl_entity(dl_se, dl_se); > > > > I am wondering if here we need a "task_non_contending(dl_se)" after > > "replenish_dl_entity(dl_se, dl_se);"... > > > > Basically, what happened is that all the served tasks blocked while the > > server was throttled... So, now the server should be disabled (so, we > > replenish the dl entity but we do not insert it in runqueue). > > But when the server finished its budget and has been throttled, it has > > not been disabled (so, its utilization is still in running_bw). > > Hummm. For CFS, we call dl_server_stop() after the last CFS task blocks > and that calls dequeue_dl(SLEEP), which should be calling > task_non_contending(). That should be happening also while the server is > throttled and CFS tasks are running outside of it, no? You are right... I somehow lost this detail. > Guess I'm missing something. No, I was the one missing something :) Sorry about the noise. Thanks, Luca