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: <2870e44f41414fd58b58f7831d7386fe@AcuMS.aculab.com>
Date:   Thu, 20 Feb 2020 14:39:51 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'chris hyser' <chris.hyser@...cle.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

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.

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.

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.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)