Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755600AbbBBN5Q (ORCPT ); Mon, 2 Feb 2015 08:57:16 -0500 Received: from mail3.unitn.it ([193.205.206.24]:53765 "EHLO mail3.unitn.it" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754325AbbBBN5O (ORCPT ); Mon, 2 Feb 2015 08:57:14 -0500 Message-ID: <54CF8234.2000308@unitn.it> Date: Mon, 02 Feb 2015 14:57:08 +0100 From: Luca Abeni User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Peter Zijlstra , Juri Lelli CC: Kirill Tkhai , Ingo Molnar , "linux-kernel@vger.kernel.org" Subject: Re: Another SCHED_DEADLINE bug (with bisection and possible fix) References: <1420633741.12772.10.camel@yandex.ru> <54B4D2DF.9010308@arm.com> <4500351421141200@web2m.yandex.ru> <20150113140436.GI25256@twins.programming.kicks-ass.net> <4632021421239387@web25g.yandex.ru> <54B7A33F.20904@unitn.it> <20150115122323.GU23965@worktop.programming.kicks-ass.net> <54B7C232.8060806@unitn.it> <20150128140803.GF23038@twins.programming.kicks-ass.net> <54CB5E56.9080506@arm.com> <20150131095659.GD32343@twins.programming.kicks-ass.net> In-Reply-To: <20150131095659.GD32343@twins.programming.kicks-ass.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1665 Lines: 42 Hi Peter, On 01/31/2015 10:56 AM, Peter Zijlstra wrote: > On Fri, Jan 30, 2015 at 10:35:02AM +0000, Juri Lelli wrote: >> So, we do the safe thing only in case of throttling. > > No, even for the !throttle aka running tasks. We only use > dl_{runtime,deadline,period} for replenishment, until that time we > observe the old runtime/deadline set by the previous replenishment. > >> I guess is more than >> ok for now, while we hopefully find some spare cycle to implement a >> complete solution :/. > > Yeah, I bet the fun part is computing the 0-lag across the entire root > domain, per-cpu 0-lag isn't correct afaict. Uhm... This is an interesting problem. I _suspect_ the 0-lag time does not depend on the number of CPUs. In other words: I _suspect_ that when you kill a SCHED_DEADLINE task its bandwidth should released at a time t0 = scheduling_deadline - current_budget / maximum_budget * period and this time is not affected by the fact that the task is scheduled by global EDF or by EDF on a single core. But I have no proof about this (and I changed my mind on this multiple times :). On a side note: as far as I can see, releasing the bandwidth at the end of the current reservation period (that is, when the time is equal to the current scheduling deadline) should be safe. Basically, by doing this we assume that the task already consumed all of its budget for the current reservation period. Luca -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/