lkml.org 
[lkml]   [2014]   [Jul]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] sched/rt: overrun could happen in start_hrtick_dl
    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
    > precision.

    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.
    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2014-07-08 11:21    [W:6.557 / U:0.032 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site