Message-ID: <454c71700907240802m19a40b83we3740aa40c3b4ae5@mail.gmail.com>
Date:	Fri, 24 Jul 2009 23:02:49 +0800
From:	sen wang <wangsen.linux@...il.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	mingo@...e.hu, akpm@...ux-foundation.org, kernel@...ivas.org,
	npiggin@...e.de, arjan@...radead.org,
	linux-arm-kernel@...ts.arm.linux.org.uk,
	linux-kernel@...r.kernel.org
Subject: Re: report a bug about sched_rt

2009/7/24 Peter Zijlstra <peterz@...radead.org>:
> 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@...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