From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751547AbdBMXnJ (ORCPT ); Mon, 13 Feb 2017 18:43:09 -0500 Received: from LGEAMRELO13.lge.com ([156.147.23.53]:41882 "EHLO lgeamrelo13.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751250AbdBMXnI (ORCPT ); Mon, 13 Feb 2017 18:43:08 -0500 X-Original-SENDERIP: 156.147.1.151 X-Original-MAILFROM: byungchul.park@lge.com X-Original-SENDERIP: 10.177.222.33 X-Original-MAILFROM: byungchul.park@lge.com Date: Tue, 14 Feb 2017 08:42:43 +0900 From: Byungchul Park To: Juri Lelli Cc: peterz@infradead.org, mingo@kernel.org, linux-kernel@vger.kernel.org, tkhai@yandex.ru, Luca Abeni Subject: Re: [PATCH] sched/deadline: Remove redundant code replenishing runtime Message-ID: <20170213234243.GO16086@X58A-UD3R> References: <1486717888-30580-1-git-send-email-byungchul.park@lge.com> <20170210133933.GA6123@e106622-lin> <20170213023009.GF16086@X58A-UD3R> <20170213042941.GG16086@X58A-UD3R> <20170213152455.GF3432@e106622-lin> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170213152455.GF3432@e106622-lin> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 13, 2017 at 03:24:55PM +0000, Juri Lelli wrote: > > > > I think we actually want to replenish and set the next deadline at this > > > > point of time, not the one that we get when the task will eventually wake up. > > > > > > Hello juri, > > > > > > But I wonder if it's meaningful to set a next deadline for a 'sleeping > > > task', which, rather, could be worse because its bandwidth might be > > > distorted at the time it's woken up. > > > > > What you mean by 'distorted'. AFAIU, we just want to replenish when > needed. The instant of time when the task will eventually wake up it is > something we cannot rely upon, and could introduce errors. > > IIUC, your situation looks like the below Exactly. > > oooo|-------------------vxxx^ooo > | | | > | | | > sleep/throttle | | > r. timer | > wakeup Sorry for bothering you.. > The task gets throttled while going to sleep, when the replenishment > timer fires you are proposing we do nothing and we actually replenishing > using the wakeup rq_clock() as reference. My worry is that, by doing so, > we make the task potentially loose some of its bandwidth, as we will > have lost some time (the 3 x-es in the diagram above) when calculating > its next dynamic deadline. I meant, when we decide whether it's overflowed in dl_entiry_overflow(), 'right' might be smaller than 'left' because 't' is the time the 3 x-es already passed. Of course, here I assumed that runtime ~= 0 and deadline ~= rq_clock when it was throttled, if scheduler works nicely. > > > IMHO, it's neat to set its deadline and runtime when being woken up, in > > > the case already passed its deadline. Am I wrong? > > > > And I found that dl_entity_overflow() returns true and replenishes the > > task unconditionally in update_dl_entity() again when the task is woken > > up, because 'runtime / (deadline - t) > dl_runtime / dl_period' is true. > > > > Why 'unconditionally'? It will postpone and replenish if the task is Not exactly 'unconditially' if my assumption is broken. Sorry for choosing a word that is not careful. > going to overflow, if not, it will keep its runtime and deadline we set I meant the task will be almost always considered 'overflow', as I explained above. So it will be overwritten again when waking up the task than keep what we set in timer callback. > when the replenishment timer fired.