Hi Michal,
> On May 21, 2019, at 6:47 AM, Michal Koutný <[email protected]> wrote:
>
> Hello Song.
>
> On Wed, Apr 10, 2019 at 07:43:35PM +0000, Song Liu <[email protected]>
> wrote:
>> The load level above is measured as requests-per-second.
>>
>> When there is no side workload, the system has about 45% busy CPU with
>> load level of 1.0; and about 75% busy CPU at load level of 1.5.
>>
>> The saturation starts before the system hitting 100% utilization. This is
>> true for many different resources: ALUs in SMT systems, cache lines,
>> memory bandwidths, etc.
> I have read through the thread continuation and it appears to me there
> is some misunderstanding on the latency metric (scheduler latency <=
> your latency <= request wall time?).
We define "your latency" == "request wall time" > "scheduler latency".
The application is a web server. It works as:
for a few iterations:
(a) request data from cache/db
(b) wait for data
(c) data is ready, wait to be scheduled
(d) render web page based on data
We need to do a few iterations because we need some data to decide what
other data to fetch.
The overall latency (or wall latency) contains:
(1) cpu time, which is (a) and (d) in the loop above;
(2) time waiting for data, which is (b);
(3) schedule latency, time between data is ready and the thread wakes
up, which is (c);
In our experiment, we can measure (1) and "(1)+(2)+(3)". For data in the
following table. "cpu time" is (1), "wall time" is (1)+(2)+(3), and
"wall - cpu" is "(2)+(3)". We assume (2) doesn't change, so changes in
"wall - cpu" is mostly due to changes in (3).
side job | cpu.headroom | cpu-idle | wall time | cpu time | wall - cpu
------------------------------------------------------------------------
none | n/a | 42.4% | 1.00 | 0.31 | 0.69
ffmpeg | 0 | 10.8% | 1.17 | 0.38 | 0.79
ffmpeg | 25% | 22.8% | 1.08 | 0.35 | 0.73
Does this make sense?
Thanks,
Song
