Received-SPF: pass (google.com: domain of linux-kernel+bounces-201109-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Message-ID: <651d11578646200cdb0a91c46ed09a22f29e94a0.camel@linux.intel.com>
Subject: Re: [PATCH v1 2/6] cpufreq: intel_pstate: Do not update
 global.turbo_disabled after initialization
From: srinivas pandruvada <srinivas.pandruvada@linux.intel.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Xi Ruoyao <xry111@xry111.site>, "Rafael J. Wysocki" <rjw@rjwysocki.net>,
  Linux PM <linux-pm@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>
Date: Tue, 04 Jun 2024 09:56:36 -0700
In-Reply-To: <CAJZ5v0jBBgjBny0Ps9bvHc7q1Un_6sdudpNL0==Z5HB+gHH0Hw@mail.gmail.com>
References: <13494237.uLZWGnKmhe@kreacher> <8366982.T7Z3S40VBb@kreacher>
	 <bf3ebf1571a4788e97daf861eb493c12d42639a3.camel@xry111.site>
	 <6d5ee74605bd9574baa5ed111cb54e959414437a.camel@linux.intel.com>
	 <6ebadacd8aaa307a5766cdb1b4d4a5c69acd87ac.camel@xry111.site>
	 <30a30c5107a47a2cc3fd39306728f70dd649d7fe.camel@linux.intel.com>
	 <f382e06635b3b52841d1e0c11dcf639d225edae0.camel@xry111.site>
	 <29d69252dcdc398f147c9139a8666d09e7bd831d.camel@linux.intel.com>
	 <0324bc3a88654855719cd48a5ed69a34eea31037.camel@xry111.site>
	 <c3526e7a0e80ec1a3a011259c38ab4b772040ea4.camel@linux.intel.com>
	 <48eba83030e155f703b4248e9c1ae65aa44b1a83.camel@xry111.site>
	 <CAJZ5v0jjLgG3VY_kBYc4mTrL2ybD2LfBTk2_H7xY0+Aq5g827A@mail.gmail.com>
	 <f34c20ae3feac0e3570125f124e440d51c5e4d9b.camel@linux.intel.com>
	 <1da736da33a61de92314934ecf7fa0420d6d6b81.camel@linux.intel.com>
	 <aa643910265b9d92a397d5148b31d37b2c421b8b.camel@xry111.site>
	 <63e98f2151ef64de92cf7e3da796937755ea5552.camel@linux.intel.com>
	 <258ce61c155c28937620f6abe57a39f2b4b0ff56.camel@xry111.site>
	 <101b903e58f2ebae60934edc374c7cda09f83de1.camel@linux.intel.com>
	 <CAJZ5v0jBBgjBny0Ps9bvHc7q1Un_6sdudpNL0==Z5HB+gHH0Hw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.48.4 (3.48.4-1.fc38) 
Precedence: bulk
MIME-Version: 1.0

On Tue, 2024-06-04 at 18:46 +0200, Rafael J. Wysocki wrote:
> On Tue, Jun 4, 2024 at 6:41=E2=80=AFPM srinivas pandruvada
> <srinivas.pandruvada@linux.intel.com> wrote:
> >=20
> > 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:
> > > > >=20
> > > > > > > > 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.
> > > > > > >=20
> > > > > > Something like the attached which does same way as user
> > > > > > space
> > > > > > no_turbo
> > > > > > update.
> > > > >=20
> > > > > > =C2=A0static int intel_pstate_register_driver(struct
> > > > > > cpufreq_driver
> > > > > > *driver)
> > > > > > =C2=A0{
> > > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 int ret;
> > > > > > @@ -3114,6 +3137,9 @@ static int
> > > > > > intel_pstate_register_driver(struct cpufreq_driver *driver)
> > > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 global.turbo_disable=
d =3D turbo_is_disabled();
> > > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 global.no_turbo =3D =
global.turbo_disabled;
> > > > > >=20
> > > > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (global.turbo_disabled=
)
> > > > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 schedule_delayed_work(&turbo_work, HZ);
> > > > > > +
> > > > >=20
> > > > > I have to change it to 20 * HZ to make it work for me.=C2=A0 15 *
> > > > > HZ
> > > > > does
> > > > > not
> > > > > work.
> > > >=20
> > > > Is there any consistency or it is changing every time?
> > >=20
> > > 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=3D"file intel_pstate.c +p" kernel command line and collect log
> > for
> > 30 seconds?
>=20
> 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.