[lkml]   [2009]   [Jul]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: report a bug about sched_rt
On Fri, 2009-07-24 at 21:44 +0800, sen wang wrote:
> 2009/7/24 Peter Zijlstra <>:
> > On Fri, 2009-07-24 at 21:26 +0800, sen wang wrote:
> >> don't tell me what theory. don't be so doctrinairism! OK?
> >> If cpu is free and there is a running state task,how can you scdedule
> >> idle task up?
> >> I tell you again:we are not talking about a bandwidth of 100% for RT!
> >> Bug lies in the bandwidth of (100- X)%.(X<100)
> >> even in the time of 100-X,if there is a rt task, you should not idle()
> >> the system.
> >
> > *sigh*
> >
> > Yes we should. I appreciate that you might assume otherwise, but you're
> > wrong. Suppose you have two competing bandwidth groups, which one will
> > run over, to what purpose?
> >
> > Also, your next top post will go to /dev/null.
> >
> OK ! maybe you has not understand what I said.
> It not two competing bandwidth groups. there is a active group and
> another is empty?
> How you do?

No, but the 1 group is the trivial case of many groups. Changing the
semantics for the trivial case is inconsistent at best, and confusing at

> Why not try it by your hand: empty the fair task, run a rt task,enable
> the bandwidth and
> see what will happen!

Oh, I know, I wrote the code.

> In many embedded system,idle task will lead to shutdown something, but
> the rt task will
> assume: when it run, idle will not happen!

How is it my problem when you design your system wrong?

If you want your 1 RT group to not get throttled, disable the throttle,
or adjust it to fit the parameters of your workload. If you don't want
idle to have latency impact on your RT tasks, fix your idle behaviour.

 \ /
  Last update: 2009-07-24 15:55    [W:0.056 / U:5.368 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site