Re: [PATCH 0/7] introduce cpu.headroom knob to cpu controller

From: Song Liu
Date: Tue May 21 2019 - 12:30:43 EST


Hi Michal,

> On May 21, 2019, at 6:47 AM, Michal Koutnà <mkoutny@xxxxxxxx> wrote:
>
> Hello Song.
>
> On Wed, Apr 10, 2019 at 07:43:35PM +0000, Song Liu <songliubraving@xxxxxx> 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