All of lore.kernel.org
 help / color / mirror / Atom feed
From: "xiaofeng.yan" <xiaofeng.yan@huawei.com>
To: Ingo Molnar <mingo@kernel.org>
Cc: <mingo@redhat.com>, <peterz@infradead.org>,
	<juri.lelli@gmail.com>, <linux-kernel@vger.kernel.org>,
	<xiaofeng.yan2012@gmail.com>
Subject: Re: [PATCH v3] sched/deadline: overrun could happen in start_hrtick_dl
Date: Fri, 15 Aug 2014 16:38:12 +0800	[thread overview]
Message-ID: <53EDC6F4.80001@huawei.com> (raw)
In-Reply-To: <20140812145254.GA7103@gmail.com>

On 2014/8/12 22:52, Ingo Molnar wrote:
> * xiaofeng.yan <xiaofeng.yan@huawei.com> 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#trace-cmd record -e sched_switch &
>> PC#./schedtool -E -t 200000:500000 -e ./test
>>
>> Some of runtime and deadline run with millisecond level by
>> reading kernershark. Some pieces of trace.dat are as follows:
>> (remove some irrelevant information)
>> <idle>-0   157.603157: sched_switch: :R ==> 2481:4294967295: test
>> test-2481  157.603203: sched_switch:  2481:R ==> 0:120: swapper/2
>> <idle>-0   157.605657: sched_switch:  :R ==> 2481:4294967295: test
>> test-2481  157.608183: sched_switch:  2481:R ==> 2483:120: trace-cmd
>> trace-cmd-2483 157.609656: sched_switch:2483:R==>2481:4294967295: test
>>
>> We can get the runtime from the information at some point.
>> runtime = 157.605657 - 157.608183
>> runtime = 0.002526(2.526ms)
>> The correct runtime should be less than or equal to 200us at some point.
>>
>> The problem is caused by a conditional judgment "delta > 10000".
>> Because no hrtimer start up to control the runtime when runtime is less than 10us.
>> So the process will continue to run until tick-period coming.
>>
>> Move the code with the limit of the least time slice
>> from hrtick_start_fair() to hrtick_start() because
>> EDF schedule class also need this function in start_hrtick_dl().
>>
>> To fix this problem, we call hrtimer_start() unconditionally in start_hrtick_dl(),
>> and make sure schedule slice won't be smaller than 10us in hrtimer_start().
>>
>> Signed-off-by: Xiaofeng Yan <xiaofeng.yan@huawei.com>
>> Reviewed-by:   Peter Zijlstra <peterz@infradead.org>
>> Reviewed-by:   Li Zefan <lizefan@huawei.com>
> The whole changelog is very hard to read and isn't proper English, nor
> is it truly explanatory. Could you please fix the changelog, or bounce
> it to someone who will fix it for you?
>
> Thanks,
>
> 	Ingo

Thanks for your reply. I will fix my change log with proper English.
Thanks
Yan
> .
>



      reply	other threads:[~2014-08-15  8:38 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-06  9:08 [PATCH v3] sched/deadline: overrun could happen in start_hrtick_dl xiaofeng.yan
2014-08-06 10:39 ` Juri Lelli
2014-08-12 14:52 ` Ingo Molnar
2014-08-15  8:38   ` xiaofeng.yan [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53EDC6F4.80001@huawei.com \
    --to=xiaofeng.yan@huawei.com \
    --cc=juri.lelli@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=xiaofeng.yan2012@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.