From: chris hyser <chris.hyser@oracle.com>
To: David Laight <David.Laight@ACULAB.COM>,
Parth Shah <parth@linux.ibm.com>,
"vincent.guittot@linaro.org" <vincent.guittot@linaro.org>,
"patrick.bellasi@matbug.net" <patrick.bellasi@matbug.net>,
"valentin.schneider@arm.com" <valentin.schneider@arm.com>,
"dhaval.giani@oracle.com" <dhaval.giani@oracle.com>,
"dietmar.eggemann@arm.com" <dietmar.eggemann@arm.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"peterz@infradead.org" <peterz@infradead.org>,
"mingo@redhat.com" <mingo@redhat.com>,
"qais.yousef@arm.com" <qais.yousef@arm.com>,
"pavel@ucw.cz" <pavel@ucw.cz>,
"qperret@qperret.net" <qperret@qperret.net>,
"pjt@google.com" <pjt@google.com>,
"tj@kernel.org" <tj@kernel.org>
Subject: Re: [PATCH v3 0/3] Introduce per-task latency_nice for scheduler hints
Date: Wed, 19 Feb 2020 12:16:59 -0500 [thread overview]
Message-ID: <10f42efa-3750-491a-74fe-d84c9c4924e3@oracle.com> (raw)
In-Reply-To: <3ce2e8940fb14d95b011c8b30892aa62@AcuMS.aculab.com>
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. :-)
>
> 1) The time taken for the (intel x86) cpu to wakeup from monitor/mwait.
> If the cpu is allowed to enter deeper sleep states this can take 900us.
> Any changes to this are system-wide not process specific.
>
> 2) If the cpu an RT process last ran on (ie the one it is woken on) is
> running in kernel, the process switch won't happen until cond_reshed()
> is called.
> On my system the code to flush the display frame buffer takes 3.3ms.
> Compiling a kernel with CONFIG_PREEMPT=y will reduce this.
>
> 3) If a hardware interrupt happens just after the process is woken
> then you have to wait until it finishes and any 'softint' work
> that is scheduled on the same cpu finishes.
> The ethernet driver transmit completions an receive ring filling
> can easily take 1ms.
> Booting with 'threadirq' might help this.
>
> 4) If you need to acquire a lock/futex then you need to allow for the
> process that holds it being delayed by a hardware interrupt (etc).
> So even if the lock is only held for a few instructions it can take
> a long time to acquire.
> (I need to change some linked lists to arrays indexed by an atomically
> incremented global index.)
>
> FWIW I can't imagine how a database can have anything that is that
> latency sensitive.
> We are doing lots of channels of audio processing and have a lot of work
> to do within 10ms to avoid audible errors.
There are existing internal numbers that I will ultimately have to duplicate that show that simply short-cutting these
idle cpu searches has a significant benefit on DB performance on large hardware. However that was for a different
patchset involving things I don't like so I'm still exploring how to achieve similar results within the latency_nice
framework.
-chrish
next prev parent reply other threads:[~2020-02-19 17:17 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-16 12:02 [PATCH v3 0/3] Introduce per-task latency_nice for scheduler hints Parth Shah
2020-01-16 12:02 ` [PATCH v3 1/3] sched: Introduce latency-nice as a per-task attribute Parth Shah
2020-01-16 12:02 ` [PATCH v3 2/3] sched/core: Propagate parent task's latency requirements to the child task Parth Shah
2020-01-16 12:02 ` [PATCH v3 3/3] sched: Allow sched_{get,set}attr to change latency_nice of the task Parth Shah
2020-02-17 8:57 ` [PATCH v3 0/3] Introduce per-task latency_nice for scheduler hints Parth Shah
2020-02-18 23:00 ` chris hyser
2020-02-19 10:09 ` Parth Shah
2020-02-19 14:15 ` chris hyser
2020-02-19 18:23 ` chris hyser
2020-02-20 8:34 ` Parth Shah
2020-02-20 8:50 ` Parth Shah
2020-02-20 14:30 ` chris hyser
2020-02-20 15:03 ` Qais Yousef
2020-02-20 16:34 ` chris hyser
2020-02-21 9:29 ` Qais Yousef
2020-02-21 10:01 ` Parth Shah
2020-02-21 16:51 ` chris hyser
2020-02-21 17:08 ` chris hyser
2020-02-21 17:52 ` chris hyser
2020-02-19 11:18 ` David Laight
2020-02-19 17:16 ` chris hyser [this message]
2020-02-20 14:39 ` David Laight
2020-02-20 15:55 ` chris hyser
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=10f42efa-3750-491a-74fe-d84c9c4924e3@oracle.com \
--to=chris.hyser@oracle.com \
--cc=David.Laight@ACULAB.COM \
--cc=dhaval.giani@oracle.com \
--cc=dietmar.eggemann@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=parth@linux.ibm.com \
--cc=patrick.bellasi@matbug.net \
--cc=pavel@ucw.cz \
--cc=peterz@infradead.org \
--cc=pjt@google.com \
--cc=qais.yousef@arm.com \
--cc=qperret@qperret.net \
--cc=tj@kernel.org \
--cc=valentin.schneider@arm.com \
--cc=vincent.guittot@linaro.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).