Hi Zoltan... On Thu, Jul 2, 2009 at 6:01 PM, Zoltan Bus<zoltan.bus@xxxxxxxxx> wrote: > On 7/1/09, Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx> wrote: >> Hi Zoltan.... >> >> On Wed, Jul 1, 2009 at 1:22 AM, Zoltan Bus<zoltan.bus@xxxxxxxxx> wrote: >> > Thank you for the answer. >> > >> > Problem found: >> > The wake_up() seems to be ok. The task is in the runqueue. Next the >> > schedule() tries to pick up the next task for context switching: >> > next = pick_next_task(rq); >> > >> > This calls pick_next_task_rt() and fails on the check: >> > >> > if (rt_rq_throttled(rt_rq)) >> > return NULL; >> > >> > The task takes roughly 20 % cpu - measured according a context >> > switching trace. Top shows 100 % cpu for that task. Probably the cpu >> > %/runtime is measured incorrectly? >> >> I think you almost solve your own puzzle here. I took very raw guess >> here that your RT task trigger CFS throttling mechanism in order to >> balance fairness. So, once this task exceed certain time interval, >> throttling took place and prevent your task to run again before >> another "sleep time" passes by. >> >> Top? oh, don't count on top too much, it has certain flaws when >> accounting %runtime. AFAIK, it measures %cpu by calculating how long >> certain task running during top's own sampling. >> >> >> regards, >> >> Mulyadi. >> > > Hi, > > just for info for other people having the same problem. > The problem is that the runtime of the real-time process is calculated > incorrectly, because we do not have a platform specific sched_clock() > function on our embedded linux port. Therefore the the default > sched_clock is used which relies on jiffies and is incremented every > 10 ms only. If the kernel tick happens between task enqueue and > dequeue, then the runtime is always incremented by 10 ms and leads to > throttling. > > Best regards, > Zoltan > May I know what your platform is? Beside that, I think this discussion is very valuable for everybody in this list. You actively provide feedback so eventually we could pinpoint the problem. Seems the port lacks hrtimer support....just my guess. regards, Mulyadi. -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
