linux-kernel - Re: [RFC] cpuidle : Add debugfs support for cpuidle core

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: <CAJZ5v0jmMwRGDY70EV3sqpw7uJ4R+VomoWtJ9rWzNTVuV3AUxQ@mail.gmail.com>
Date:   Tue, 17 Dec 2019 17:51:09 +0100
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     Abhishek Goel <huntbag@...ux.vnet.ibm.com>
Cc:     Linux PM <linux-pm@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        "Gautham R. Shenoy" <ego@...ux.vnet.ibm.com>,
        "Oliver O'Halloran" <oohall@...il.com>,
        Michael Ellerman <mpe@...erman.id.au>, svaidy@...ux.ibm.com
Subject: Re: [RFC] cpuidle : Add debugfs support for cpuidle core

On Tue, Dec 17, 2019 at 3:42 PM Abhishek Goel
<huntbag@...ux.vnet.ibm.com> wrote:
>
> Up until now, we did not have a way to tune cpuidle attribute like
> residency in kernel. This patch adds support for debugfs in cpuidle core.
> Thereby providing support for tuning cpuidle attributes like residency in
> kernel at runtime.

This is not a good idea in my view, for a couple of reasons.

First off, if the target residency of an idle state is changed, it
effectively becomes a different one and all of the statistics
regarding it become outdated at that point.  Synchronizing that would
be a pain.

Next, governors may get confused if idle state parameters are changed
on the fly.  In particular, the statistics collected by the teo
governor depend on the target residencies of idle states, so if one of
them changes, the governor needs to be reloaded.

Next, idle states are expected to be ordered by the target residency
(and by the exit latency), so their parameters cannot be allowed to
change freely anyway.

Finally, the idle state parameters are expected to reflect the
properties of the hardware, which wouldn't hold any more if they were
allowed to change at any time.

> For example: Tuning residency at runtime can be used to quantify governors
> decision making as governor uses residency as one of the parameter to
> take decision about the state that needs to be entered while idling.

IMO it would be better to introduce a testing cpuidle driver with an
artificial set of idle states (or even such that the set of idle
states to be used by it can be defined by the user e.g. via module
parameters) for this purpose.