linux-kernel - Re: [PATCH v1 2/6] cpufreq: intel_pstate: Do not update global.turbo

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: <651d11578646200cdb0a91c46ed09a22f29e94a0.camel@linux.intel.com>
Date: Tue, 04 Jun 2024 09:56:36 -0700
From: srinivas pandruvada <srinivas.pandruvada@...ux.intel.com>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: Xi Ruoyao <xry111@...111.site>, "Rafael J. Wysocki" <rjw@...ysocki.net>,
  Linux PM <linux-pm@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1 2/6] cpufreq: intel_pstate: Do not update
 global.turbo_disabled after initialization

On Tue, 2024-06-04 at 18:46 +0200, Rafael J. Wysocki wrote:
> On Tue, Jun 4, 2024 at 6:41 PM srinivas pandruvada
> <srinivas.pandruvada@...ux.intel.com> wrote:
> > 
> > On Tue, 2024-06-04 at 18:32 +0800, Xi Ruoyao wrote:
> > > On Tue, 2024-06-04 at 03:29 -0700, srinivas pandruvada wrote:
> > > > On Tue, 2024-06-04 at 17:30 +0800, Xi Ruoyao wrote:
> > > > > On Mon, 2024-06-03 at 21:31 -0700, srinivas pandruvada wrote:
> > > > > 
> > > > > > > > Second, a delayed work can be added to check the MSR
> > > > > > > > long
> > > > > > > > enough
> > > > > > > > after
> > > > > > > > initialization and update global.turbo_disabled if it
> > > > > > > > is 1.
> > > > > > > > However,
> > > > > > > > that would require some code surgery.
> > > > > > > 
> > > > > > Something like the attached which does same way as user
> > > > > > space
> > > > > > no_turbo
> > > > > > update.
> > > > > 
> > > > > >  static int intel_pstate_register_driver(struct
> > > > > > cpufreq_driver
> > > > > > *driver)
> > > > > >  {
> > > > > >         int ret;
> > > > > > @@ -3114,6 +3137,9 @@ static int
> > > > > > intel_pstate_register_driver(struct cpufreq_driver *driver)
> > > > > >         global.turbo_disabled = turbo_is_disabled();
> > > > > >         global.no_turbo = global.turbo_disabled;
> > > > > > 
> > > > > > +       if (global.turbo_disabled)
> > > > > > +               schedule_delayed_work(&turbo_work, HZ);
> > > > > > +
> > > > > 
> > > > > I have to change it to 20 * HZ to make it work for me.  15 *
> > > > > HZ
> > > > > does
> > > > > not
> > > > > work.
> > > > 
> > > > Is there any consistency or it is changing every time?
> > > 
> > > It seems consistent.
> > With such a delay, I am not sure how this even worked before.
> > Can you revert the patch in question and use kernel dynamic debug
> > dyndbg="file intel_pstate.c +p" kernel command line and collect log
> > for
> > 30 seconds?
> 
> I think that it worked because the MSR was read every time
> intel_pstate ran, so it got updated at one point and stayed that way.

But here HWP in active mode is getting used. So it should have fewer
request calls to set accept via cpufreq set_policy()

 callback or with some HWP interrupt.