Messages in this thread | | | Date | Fri, 24 Jul 2009 23:02:49 +0800 | Subject | Re: report a bug about sched_rt | From | sen wang <> |
| |
2009/7/24 Peter Zijlstra <peterz@infradead.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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |