[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9d2882f2877e52c611362dc7e3699eca1e715695.camel@linux.intel.com>
Date: Mon, 03 Sep 2018 08:15:31 -0700
From: Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>
To: Eero Tamminen <eero.t.tamminen@...el.com>, lenb@...nel.org,
rjw@...ysocki.net, viresh.kumar@...aro.org
Cc: mgorman@...hsingularity.net, currojerez@...eup.net,
ggherdovich@...e.cz, peterz@...radead.org,
linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] cpufreq: intel_pstate: Optimize IO boost in non HWP mode
On Mon, 2018-09-03 at 18:10 +0300, Eero Tamminen wrote:
> Hi,
>
> On 31.08.2018 20:28, Srinivas Pandruvada wrote:
> ...
> > As per testing Eero Tamminen, the results are comparable to the
> > patchset
> > https://patchwork.kernel.org/patch/10312259/
> > But he has to watch results for several days to check trend.
>
> It's close, but there is some gap compared to Francisco's version.
>
> (Because of the large variance on TDP limited devices, and factors
> causing extra perf differences e.g. between boots, it's hard to give
> exact number without having trends from several days / weeks. I
> would
> also need new version of Fransisco's patch set that applies to
> latest
> kernel like yours does.)
>
>
> > Since here boost is getting limited to turbo and non turbo, we need
> > some
> > ways to adjust the fractions corresponding to max non turbo as
> > well. It
> > is much easier to use the actual P-state limits for boost instead
> > of
> > fractions. So here P-state io boost limit is applied on top of the
> > P-state limit calculated via current algorithm by removing current
> > io_wait boost calculation using fractions.
> >
> > Since we prefer to use common algorithm for all processor
> > platforms, this
> > change was tested on other client and sever platforms as well. All
> > results
> > were within the margin of errors. Results:
> > https://bugzilla.kernel.org/attachment.cgi?id=278149
>
> Good.
>
> Francisco, how well the listed PTS tests cover latency bound cases
> you
> were concerned about? [1]
>
>
> - Eero
>
> [1] Fransisco was concerned that the patch:
> * trade-off might regress latency bound cases (which I haven't
> tested, I
> tested only 3D throughput), and
> * that it addressed only other of the sources of energy
> inefficiencies
> he had identified (which could explain slightly better 3D results
> from
> his more complex patch set).
It is always possible to submit improvement patch later. Atleast this
patch will reduce the usage of turbo.
Thanks,
Srinivas
Powered by blists - more mailing lists