Re: [PATCH] sched/rt: overrun could happen in start_hrtick_dl

From: xiaofeng.yan
Date: Tue Jul 08 2014 - 04:43:35 EST

On 2014/7/8 15:49, Peter Zijlstra wrote:
On Tue, Jul 08, 2014 at 10:51:02AM +0800, xiaofeng.yan wrote:
On 2014/7/8 10:40, Li Zefan wrote:
On 2014/7/8 9:10, xiaofeng.yan wrote:
On 2014/7/7 16:41, Peter Zijlstra wrote:
On Fri, Jul 04, 2014 at 12:02:21PM +0000, xiaofeng.yan wrote:
It could be wrong for the precision of runtime and deadline
when the precision is within microsecond level. For example:
Task runtime deadline period
P1 200us 500us 500us

This case need enbale HRTICK feature by the next command
PC#echo "HRTICK" > /sys/kernel/debug/sched_features
PC#./schedtool -E -t 200000:500000 -e ./test&
PC#trace-cmd record -e sched_switch
Are you actually using HRTICK ?
yes, If HRTICK is close , then all of runtime and deadline will be wrong.
I think what peter meant is, do you use HRTICK in products or
just use it for testing/experiment?

Thanks for your timely comments. In fact, We use HRTICK feature in product.
We need microsecond level
Ah, thanks. Be advised that currently HRTICK is rather expensive. The
cost is twofold: 1) doing all the kernel side hrtimer things and 2)
programming clock hardware.

Of course, if that's what you need, you're willing to pay the price.

I'll see if I can put making it less expensive slightly higher on the
(endless) todo list.

another fold: 3) Frequent migration :)
In fact, frequent migration lead to higher overload. In our product we design new migration solution.
The simple description is as follow:
1 Set affinity in user space program at the beginning
2 Migrate happen per 100ms
3 Free task (runtime < dl_runtime)is migrated to free cpu (rt task bandwidth < 65%) .
4 Busy task will run more time in a CPU by dynamic quota.
So the condition of migration depends on whether task is busy or idle or not instead of deadline at some point.
This could not meet EDF requirement but meet our product :)

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at