Re: report a bug about sched_rt

[Peter Zijlstra]

On Fri, 2009-07-24 at 21:44 +0800, sen wang wrote:
> 2009/7/24 Peter Zijlstra <peterz@xxxxxxxxxxxxx>:
> > 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
worst.

> 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.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/