linux-kernel - Re: [PATCH v3 0/3] Introduce per-task latency

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]

Message-ID: <7b50c0ee-5e2b-5cec-a7f6-514abdc5ee18@oracle.com>
Date:   Thu, 20 Feb 2020 10:55:58 -0500
From:   chris hyser <chris.hyser@...cle.com>
To:     David Laight <David.Laight@...LAB.COM>,
        Parth Shah <parth@...ux.ibm.com>,
        "vincent.guittot@...aro.org" <vincent.guittot@...aro.org>,
        "patrick.bellasi@...bug.net" <patrick.bellasi@...bug.net>,
        "valentin.schneider@....com" <valentin.schneider@....com>,
        "dhaval.giani@...cle.com" <dhaval.giani@...cle.com>,
        "dietmar.eggemann@....com" <dietmar.eggemann@....com>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "qais.yousef@....com" <qais.yousef@....com>,
        "pavel@....cz" <pavel@....cz>,
        "qperret@...rret.net" <qperret@...rret.net>,
        "pjt@...gle.com" <pjt@...gle.com>, "tj@...nel.org" <tj@...nel.org>
Subject: Re: [PATCH v3 0/3] Introduce per-task latency_nice for scheduler
 hints



On 2/20/20 9:39 AM, David Laight wrote:
> From: chris hyser <chris.hyser@...cle.com>
>> Sent: 19 February 2020 17:17
>>
>> On 2/19/20 6:18 AM, David Laight wrote:
>>> From: chris hyser
>>>> Sent: 18 February 2020 23:00
>>> ...
>>>> All, I was asked to take a look at the original latency_nice patchset.
>>>> First, to clarify objectives, Oracle is not
>>>> interested in trading throughput for latency.
>>>> What we found is that the DB has specific tasks which do very little but
>>>> need to do this as absolutely quickly as possible, ie extreme latency
>>>> sensitivity. Second, the key to latency reduction
>>>> in the task wakeup path seems to be limiting variations of "idle cpu" search.
>>>> The latter particularly interests me as an example of "platform size
>>>> based latency" which I believe to be important given all the varying size
>>>> VMs and containers.
>>>
>>>   From my experiments there are a few things that seem to affect latency
>>> of waking up real time (sched fifo) tasks on a normal kernel:
>>
>> Sorry. I was only ever talking about sched_other as per the original patchset. I realize the term
>> extreme latency
>> sensitivity may have caused confusion. What that means to DB people is no doubt different than audio
>> people. :-)
> 
> Shorter lines.....
> 
> ISTM you are making some already complicated code even more complex.
> Better to make it simpler instead.

The code already exists to set a limit to bail out of what is sometimes a needlessly excessive search. Setting that 
based on an integer doesn't seem particularly complex. Now whether that is actually useful is what I'm currently looking at.

> 
> If you need a thread to run as soon as possible after it is woken
> why not use the RT scheduler (eg SCHED_FIFO) that is what it is for.

Overkill and doesn't play well with cpu cgroup controller.


> 
> If there are delays finding an idle cpu to migrate a process to
> (especially on systems with large numbers of cpu) then that is a
> general problem that can be addressed without extra knobs.

There is no if. It is a brute force search. There are delays proportional to the search domain size. You can optimize 
the hell of out the brute force, or you use obtained knowledge to bail out early. Getting that knowledge from the user 
is a time honored tradition. :-)

-chrish