[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191125091637.GB3016@techsingularity.net>
Date: Mon, 25 Nov 2019 09:16:37 +0000
From: Mel Gorman <mgorman@...hsingularity.net>
To: Doug Smythies <dsmythies@...us.net>
Cc: 'Giovanni Gherdovich' <ggherdovich@...e.cz>,
'Srinivas Pandruvada' <srinivas.pandruvada@...ux.intel.com>,
'Thomas Gleixner' <tglx@...utronix.de>,
'Ingo Molnar' <mingo@...hat.com>,
'Peter Zijlstra' <peterz@...radead.org>,
'Borislav Petkov' <bp@...e.de>, 'Len Brown' <lenb@...nel.org>,
"'Rafael J . Wysocki'" <rjw@...ysocki.net>, x86@...nel.org,
linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
'Matt Fleming' <matt@...eblueprint.co.uk>,
'Viresh Kumar' <viresh.kumar@...aro.org>,
'Juri Lelli' <juri.lelli@...hat.com>,
'Paul Turner' <pjt@...gle.com>,
'Vincent Guittot' <vincent.guittot@...aro.org>,
'Quentin Perret' <qperret@...rret.net>,
'Dietmar Eggemann' <dietmar.eggemann@....com>
Subject: Re: [PATCH v4 1/6] x86,sched: Add support for frequency invariance
On Sat, Nov 23, 2019 at 11:49:57PM -0800, Doug Smythies wrote:
> Hi all,
>
> The address list here is likely incorrect,
> and this e-mail is really about a kernel 5.4
> bisected regression.
>
> It had been since mid September, and kernel 5.3-rc8 since
> I had tried this, so I wanted to try it again. Call it due diligence.
> I focused on my own version of the "gitsource" test.
>
> Kernel 5.4-rc8 (as a baseline reference).
>
> My results were extremely surprising.
>
> As it turns out, at least on my test computer, both the
> acpi-cpufreq and intel_cpufreq CPU frequency scaling drivers
> using the schedutil governor are broken. For the tests that
> I ran, there is negligible difference between them and the
> performance governor. So, one might argue that they are not
> broken, but rather working incredibly well, which if true
> then this patch is no longer needed.
>
I don't think that is necessarily fair. It still makes sense that the
"size" of a task is independent of the frequency the CPU is running at
for load balancing decisions and should be merged on that basis alone. If
the scheduler made perfect decisions on task location then there would
be negligible difference between ondemand (or powersave if intel_pstate)
and performance governor too. cpufreq tends to be more noticable under
the current implementation as tasks are a lot more mobile than they need
to be for basic workloads.
--
Mel Gorman
SUSE Labs
Powered by blists - more mailing lists