linux-kernel - Re: [RFC][PATCH] thermal/idle_inject: Support 100% idle injection

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: <838cf73badd8e0c1126dbc64db3aed2f20cbfe9c.camel@linux.intel.com>
Date:   Wed, 21 Dec 2022 12:36:14 -0800
From:   srinivas pandruvada <srinivas.pandruvada@...ux.intel.com>
To:     Daniel Lezcano <daniel.lezcano@...aro.org>, rafael@...nel.org
Cc:     linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCH] thermal/idle_inject: Support 100% idle injection

On Wed, 2022-12-21 at 14:43 +0100, Daniel Lezcano wrote:
> 
> Hi Srinivas,
> 
> 
> On 09/12/2022 02:36, Srinivas Pandruvada wrote:
> > The users of idle injection framework allow 100% idle injection.
> > For
> > example: thermal/cpuidle_cooling.c driver. When the ratio set to
> > 100%,
> > the runtime_duration becomes zero.
> > 
> > In the function idle_inject_set_duration() in idle injection
> > framework
> > run_duration_us == 0 is silently ignored, without any error (it is
> > a
> > void function). So, the caller will assume that everything is fine
> > and
> > 100% idle is effective. But in reality the idle inject will be
> > whatever
> > set before.
> 
> Good catch
> 
> > There are two options:
> > - The caller change their max state to 99% instead of 100% and
> > document that 100% is not supported by idle inject framework
> > - Support 100% idle support in idle inject framework
> 
> Yes, from my POV a CPU being impossible to cool down for any reason 
> should end up by staying off.
> 
> > Since there are other protections via RT throttling, this framework
> > can
> > allow 100% idle. The RT throttling will be activated at 95% idle by
> > default. The caller disabling RT throttling and injecting 100%
> > idle,
> > should be aware that CPU can't be used at all.
> 
> Would it make sense to write a trace in this case ?

There is one printk already:
printk_deferred_once("sched: RT throttling activated\n")

You mean we should add

trace_sched_* for this?

> 
> > The idle inject timer is started for (run_duration_us +
> > idle_duration_us)
> > duration. Hence replace (run_duration_us && idle_duration_us) with
> > (run_duration_us + idle_duration_us) in the function
> > idle_inject_set_duration().
> 
> Sounds good to me
> 
I will submit a patch for this.

Thanks,
Srinivas

> > Signed-off-by: Srinivas Pandruvada
> > <srinivas.pandruvada@...ux.intel.com>
> > ---
> >   drivers/powercap/idle_inject.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/powercap/idle_inject.c
> > b/drivers/powercap/idle_inject.c
> > index f48e71501429..4a4fe60d2563 100644
> > --- a/drivers/powercap/idle_inject.c
> > +++ b/drivers/powercap/idle_inject.c
> > @@ -184,7 +184,7 @@ void idle_inject_set_duration(struct
> > idle_inject_device *ii_dev,
> >                               unsigned int run_duration_us,
> >                               unsigned int idle_duration_us)
> >   {
> > -       if (run_duration_us && idle_duration_us) {
> > +       if (run_duration_us + idle_duration_us) {
> >                 WRITE_ONCE(ii_dev->run_duration_us,
> > run_duration_us);
> >                 WRITE_ONCE(ii_dev->idle_duration_us,
> > idle_duration_us);
> >         }
>