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] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 15 May 2017 11:50:17 +0800
From:   Xunlei Pang <xpang@...hat.com>
To:     luca abeni <luca.abeni@...tannapisa.it>
Cc:     Xunlei Pang <xlpang@...hat.com>, linux-kernel@...r.kernel.org,
        Peter Zijlstra <peterz@...radead.org>,
        Juri Lelli <juri.lelli@....com>,
        Ingo Molnar <mingo@...hat.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Daniel Bristot de Oliveira <bristot@...hat.com>,
        Luca Abeni <luca.abeni@...tn.it>
Subject: Re: [PATCH v2 2/3] sched/deadline: Throttle the task when missing its
 deadline

On 05/13/2017 at 04:58 AM, luca abeni wrote:
> On Fri, 12 May 2017 15:19:55 +0800
> Xunlei Pang <xpang@...hat.com> wrote:
> [...]
>>>>  "As seen, enforcing that the total utilization is smaller than M
>>>> does not guarantee that global EDF schedules the tasks without
>>>> missing any deadline (in other words, global EDF is not an optimal
>>>> scheduling algorithm). However, a total utilization smaller than M
>>>> is enough to guarantee that non real-time tasks are not starved
>>>> and that the tardiness of real-time tasks has an upper bound[12]
>>>> (as previously noted). Different bounds on the maximum tardiness
>>>> experienced by real-time tasks have been developed in various
>>>> papers[13,14], but the theoretical result that is important for
>>>> SCHED_DEADLINE is that if the total utilization is smaller or equal
>>>> than M then the response times of the tasks are limited."
>>>>
>>>> Do you mean there is some tardiness allowed in theory(global EDF is
>>>> not an optimal scheduling algorithm), thus missed deadline is
>>>> allowed for global EDF?  
>>> Right.
>>>
>>> With the admission test currently used by the kernel (sum of
>>> utilizations <= 1), tasks are guaranteed to have a tardiness smaller
>>> than a theoretical maximum... But this theoretical maximum can be
>>> larger than 0.
>>>
>>> If you want to strictly respect all of the deadlines, you need a
>>> stricter admission test (for example, the one based on WCET_max
>>> that is mentioned above).  
>> Understood.
>>
>> I think in Patch 3, it is still worthy to add the accounting in
>> dl_runtime_exceeded(), to track the dl scheduling tardiness(after all
>> tardiness is not a good thing) like: if
>> (dl_time_before(dl_se->deadline, rq_clock(rq)) && dl_se->runtime > 0)
>> ++dl_se->nr_underrun_sched;
>>
>> Maybe changing the name to use "nr_underrun_tardy" is better, large
>> value does need our attention. What do you think?
> I do not know, I never used statistics like these...
>
> If there are enough people having a good usecase for these statistics,
> it might be worth adding them, but I do not know other people's
> opinions about this.
>

Hi Luca,

Thanks for the feedback.

I think I can defer the statistics patch after Daniel's "sched/deadline: Use the
revised wakeup rule for suspending constrained dl tasks", since there will
be another underrun case in the fix, let's wait for other's opinions then.

Regards,
Xunlei

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ