linux-kernel - Re: [PATCH] sched/rt: overrun could happen in start_hrtick

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <53BBAEBF.4010107@huawei.com>
Date:	Tue, 8 Jul 2014 16:41:35 +0800
From:	"xiaofeng.yan" <xiaofeng.yan@...wei.com>
To:	Peter Zijlstra <peterz@...radead.org>
CC:	Li Zefan <lizefan@...wei.com>, <mingo@...hat.com>,
	<linux-kernel@...r.kernel.org>, <xiaofeng.yan2012@...il.com>,
	Juri Lelli <juri.lelli@...il.com>
Subject: Re: [PATCH] sched/rt: overrun could happen in start_hrtick_dl

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
>> 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.

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/