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

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]

Date:   Tue, 21 May 2019 16:27:02 +0000
From:   Song Liu <songliubraving@...com>
To:     Michal Koutný <mkoutny@...e.com>
CC:     Morten Rasmussen <morten.rasmussen@....com>,
        Kernel Team <Kernel-team@...com>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "vincent.guittot@...aro.org" <vincent.guittot@...aro.org>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "cgroups@...r.kernel.org" <cgroups@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/7] introduce cpu.headroom knob to cpu controller

Hi Michal,

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