[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <128831392982418@web15j.yandex.ru>
Date: Fri, 21 Feb 2014 15:33:38 +0400
From: Kirill Tkhai <tkhai@...dex.ru>
To: Peter Zijlstra <peterz@...radead.org>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Juri Lelli <juri.lelli@...il.com>,
Steven Rostedt <rostedt@...dmis.org>,
Ingo Molnar <mingo@...hat.com>
Subject: Re: [RFC] sched/deadline: Prevent rt_time growth to infinity
21.02.2014, 14:37, "Peter Zijlstra" <peterz@...radead.org>:
> 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.
> ---
> --- a/kernel/sched/rt.c
> +++ b/kernel/sched/rt.c
> @@ -568,6 +568,12 @@ static inline struct rt_bandwidth *sched
[snipped by dumb mail client]
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists