Re: report a bug about sched_rt

[sen wang]

2009/7/24 Peter Zijlstra <peterz@xxxxxxxxxxxxx>:
> On Fri, 2009-07-24 at 22:24 +0800, sen wang wrote:
>
>> > 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.
>
>> yes! 1 group is the trivial case ,but you can't say it is useless. and
>> in some system
>> it is important!
>> I have read across the schedule codes and tried this way,it work:
>> static struct task_struct *pick_next_task_rt(struct rq *rq)
>> { ...
>> Â Â Â Âif (rt_rq_throttled(rt_rq)&& rq->cfs.nr_running)
>> Â Â Â Â Â Â Â Âreturn NULL;
>> ....
>> }
>
> That might work in the current implementation, but like I already
> explained, its not consistent with the multi-group case. Also, people
> are working on making it a proper EDF scheduled CBS, it won't
> generalize.
>
>> > How is it my problem when you design your system wrong?
>>
>> my system is good. but there is no rules what the idle task will do,so.
>> people always write codes in idle task with the assume: no any running
>> task in the system.
>> and people also always write codes in rt task with the assume: if I am
>> in running state
>> ,system will not idle.
>>
>> so what i said above is some like theory,but I don't like the word âtheory".
>> I call it people's common sense.
>>
>> but the behavior of the Âthrottled RT group is changed from people's
>> common sense,so don't say people's common sense is wrong. OK?
>
> There are plenty of examples where common sense utterly fails, the one
> that comes to mind is Probability Theory.
>
>> > 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.
>> >
>>
>> 1 RT is important to me. But I also have fair task, so Âthrottled is
>> also important to me.
>> and don't say : idle have latency impact on RT tasks. It is too
>> ludicrous Why we make  intended latency impact by ourselves,by wrong
>> idle task?
>
> Yes, configurable idle tasks are nothing new. If you care about wakeup
> latency then idle=poll is preferred (it sucks for power saving, but such
> is life).
>
> On your embedded board you seem to have a particularly aggressive idle
> function wrt power savings, which would result in rather large wake from
> idle latencies, regardless of the bandwidth throttle, so what is the
> problem?
>
don't guess what i do in my idle? my idle is perfect!
and don't think only you understand the scheduling and waht you
consider is right.
linux is a free world.

> If you're using the bandwidth throttle to control your RT tasks so as
> not to starve your SCHED_OTHER tasks, then I will call your system ill
> designed.
>
 the bandwidth throttle to control RT tasks is useful.  of course , I know how
not to prevent SCHED_OTHER tasks from being starved. we just discuss how to
deal with the 100-X time. and very unfortunatly,you are wrong.
--
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/