On Fri, 21 Feb 2014 16:09:25 +0400 Kirill Tkhai <[email protected]> wrote:
> > > 21.02.2014, 15:39, "Kirill Tkhai" <[email protected]>: > > 21.02.2014, 14:37, "Peter Zijlstra" <[email protected]>: > > > >> On Thu, Feb 20, 2014 at 02:16:00AM +0400, Kirill Tkhai wrote: > >>> Since deadline tasks share rt bandwidth, we must care about > >>> bandwidth timer set. Otherwise rt_time may grow up to infinity > >>> in update_curr_dl(), if there are no other available RT tasks > >>> on top level bandwidth. > >>> > >>> I'm going to decide the problem the way below. Almost untested > >>> because of I skipped almost all of recent patches which haveto be > >>> applied from lkml. > >>> > >>> Please say, if I skipped anything in idea. Maybe better put > >>> start_top_rt_bandwidth() into set_curr_task_dl()? > >> How about we only increment rt_time when there's an RT bandwidth timer > >> active? > > > > This case RT and DL may eat all the time: > > > > -------------- time ------------------> > > |RT's working |DL's working| > > ---------------------------- > > |rt_runtime | | > > ---------------------------- > > | rt_period | > > > > Or at least more, than it's allowed. > > > > It looks like, if we want to limit time of high priority classes > > execution, we have to set the timer anyway. > > Oh, above is confusing. Sorry. > > I mean one RT task and > > ----------------- time --------------------------> > |DL's working |RT's working| |DL's working | > -------------------------------------------------- > | |rt_runtime | | | > -------------------------------------------------- > | | rt_period | | > > In this case FAIR receives less ratio, than (rt_period-rt_runtime)/rt_period. > DL tasks won't be allowed to run in this situation, as their bw exceedes rt_runtime/rt_period. Thanks, - Juri -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
