The device_reset() function is marked as "__must_check", thus the static
analysis tool "sparse" complains that in ralink-gdma its return value is
ignored. Log a warning in case it returns an error.
Signed-off-by: Giovanni Gherdovich
---
drivers/staging/ralink-gdma/ralink-gdm
uency table of the CPU.
>
> Please test this one and let me know if it adversely affects performance.
>
> Thanks!
Hello Rafael,
more extended testing confirms the initial feeling; performance with this
patch is mostly identical to vanilla v5.11. Tbench shows an improvement.
Thanks f
On Mon, 2021-02-15 at 20:24 +0100, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Commit 3c55e94c0ade ("cpufreq: ACPI: Extend frequency tables to cover
> boost frequencies") attempted to address a performance issue involving
> acpi-cpufreq, the schedutil governor and scale-invariance on x
kernel/smpboot.c
> @@ -1833,6 +1833,7 @@ void arch_set_max_freq_ratio(bool turbo_
> arch_max_freq_ratio = turbo_disabled ? SCHED_CAPACITY_SCALE :
> arch_turbo_freq_ratio;
> }
> +EXPORT_SYMBOL_GPL(arch_set_max_freq_ratio);
>
> static bool turbo_disabled(void)
> {
Reviewed-by: Giovanni Gherdovich
Thanks,
Giovanni
)
> Link:
> https://www.phoronix.com/scan.php?page=article&item=linux511-amd-schedutil&num=1
> Link:
> https://lore.kernel.org/linux-pm/20210203135321.12253-2-ggherdov...@suse.cz/
> Reported-by: Michael Larabel
> Diagnosed-by: Giovanni Gherdovich
> Signed-off-by: Rafa
On Wed, 2021-02-03 at 19:25 +0100, Rafael J. Wysocki wrote:
> [cut]
>
> So below is a prototype of an alternative fix for the issue at hand.
>
> I can't really test it here, because there's no _CPC in the ACPI tables of my
> test machines, so testing it would be appreciated. However, AFAICS thes
orth (it's a
feedback loop).
Fixes: 41ea667227ba ("x86, sched: Calculate frequency invariance for AMD
systems")
Fixes: 976df7e5730e ("x86, sched: Use midpoint of max_boost and max_P for
frequency invariance on AMD EPYC")
Reported-by: Michael Larabel
Tested-by: Michael L
v2 at https://lore.kernel.org/lkml/20210122204038.3238-1-ggherdov...@suse.cz
Changes wrt v2:
- removed redundant "#ifdef CONFIG_ACPI_CPPC_LIB"
Giovanni Gherdovich (1):
x86,sched: On AMD EPYC set freq_max = max_boost in schedutil invariant
formula
drivers/cpufreq/acpi-cpufre
On Tue, 2021-02-02 at 20:11 +0100, Rafael J. Wysocki wrote:
> On Tue, Feb 2, 2021 at 7:45 PM Rafael J. Wysocki wrote:
> >
> > On Tue, Jan 26, 2021 at 5:19 PM Giovanni Gherdovich
> > wrote:
> > >
> > >
> > > cpufreq core ask
On Tue, 2021-02-02 at 19:59 +0100, Rafael J. Wysocki wrote:
> On Fri, Jan 22, 2021 at 9:47 PM Giovanni Gherdovich
> wrote:
> >
>
> [cut]
>
> > diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
> > index 1e4fbb002a31..2378bc1bf2c4
59 PM Rafael J. Wysocki wrote:
> >
> > On Fri, Jan 22, 2021 at 9:47 PM Giovanni Gherdovich
> > wrote:
> >
> > [cut]
> > > @@ -779,15 +829,25 @@ static int acpi_cpufreq_cpu_init(struct
> > > cpufreq_policy *policy
On Fri, 2021-01-29 at 16:23 +0100, Giovanni Gherdovich wrote:
> On Tue, 2021-01-26 at 11:05 +0100, Peter Zijlstra wrote:
> > On Tue, Jan 26, 2021 at 09:31:40AM +, Mel Gorman wrote:
> >
> > > So, should this patch be merged for 5.11 as a stopgap, fix up
> > >
On Mon, 2021-01-25 at 11:06 +0100, Peter Zijlstra wrote:
> On Fri, Jan 22, 2021 at 09:40:38PM +0100, Giovanni Gherdovich wrote:
> > 1. PROBLEM DESCRIPTION (over-utilization and schedutil)
> >
> > The problem happens on CPU-bound workloads spanning a large number of co
On Mon, 2021-01-25 at 11:04 +0100, Peter Zijlstra wrote:
> On Fri, Jan 22, 2021 at 09:40:38PM +0100, Giovanni Gherdovich wrote:
> > This workload is constant in time, so instead of using the PELT sum we can
> > pretend that scale invariance is obtained with
> >
> &
On Mon, 2021-01-25 at 09:34 +0100, Peter Zijlstra wrote:
> On Sun, Jan 24, 2021 at 04:30:57PM -0600, Michael Larabel wrote:
> > From ongoing tests of this patch, it still certainly shows to address most
> > of the Linux 5.11 performance regression previously encountered when using
> > Schedutil. Ad
an
improvement over the v5.10 results.
Thanks Michael for the feedback!
v1 at https://lore.kernel.org/lkml/20210121003223.20257-1-ggherdov...@suse.cz/
Changes wrt v1:
- move code around so that it builds for non-x86 architectures too
Giovanni Gherdovich (1):
x86,sched: On AMD EPYC set
orth (it's a
feedback loop).
Fixes: 41ea667227ba ("x86, sched: Calculate frequency invariance for AMD
systems")
Fixes: 976df7e5730e ("x86, sched: Use midpoint of max_boost and max_P for
frequency invariance on AMD EPYC")
Reported-by: Michael Larabel
Signed-off-by:
On Thu, 2021-01-21 at 01:35 +0100, Giovanni Gherdovich wrote:
> Phoronix.com discovered a severe performance regression on AMD APYC
> introduced on schedutil [see link 1] by the following commits from v5.11-rc1
>
> commit 41ea667227ba ("x86, sched: Calculate frequency i
orth (it's a
feedback loop).
Fixes: 41ea667227ba ("x86, sched: Calculate frequency invariance for AMD
systems")
Fixes: 976df7e5730e ("x86, sched: Use midpoint of max_boost and max_P for
frequency invariance on AMD EPYC")
Signed-off-by: Giovanni Gherdovic
orth (it's a
feedback loop).
Fixes: 41ea667227ba ("x86, sched: Calculate frequency invariance for AMD
systems")
Fixes: 976df7e5730e ("x86, sched: Use midpoint of max_boost and max_P for
frequency invariance on AMD EPYC")
Signed-off-by: Giovanni Gherdovic
r).
>
> Fixes: e2b0d619b400 ("x86, sched: check for counters overflow in frequency
> invariant accounting")
> Signed-off-by: Rafael J. Wysocki
>
Thanks for writing this, Rafael.
Peter Zijlstra asked to fix this problem months ago; I started but
got stucked and never finished.
Giovanni Gherdovich
On Mon, 2020-12-21 at 17:11 +0100, Rafael J. Wysocki wrote:
> Hi,
>
> On Fri, Dec 18, 2020 at 5:22 PM Giovanni Gherdovich wrote:
> >
> > Gitsource: this test show the most compelling case against the
> > sugov-HWP.desired series: on the Cascade Lake sugov-HWP.de
On Mon, 2020-12-14 at 21:01 +0100, Rafael J. Wysocki wrote:
> Hi,
>
> The timing of this is not perfect (sorry about that), but here's a refresh
> of this series.
>
> The majority of the previous cover letter still applies:
> [...]
Hello,
the series is tested using
-> tbench (packets processin
The following commit has been merged into the sched/core branch of tip:
Commit-ID: 976df7e5730e3ec8a7e192c09c10ce6e8db07e65
Gitweb:
https://git.kernel.org/tip/976df7e5730e3ec8a7e192c09c10ce6e8db07e65
Author:Giovanni Gherdovich
AuthorDate:Thu, 12 Nov 2020 19:26:13 +01:00
The following commit has been merged into the sched/core branch of tip:
Commit-ID: 3149cd55302748df771dc1c8c10f34b1cbce88ed
Gitweb:
https://git.kernel.org/tip/3149cd55302748df771dc1c8c10f34b1cbce88ed
Author:Giovanni Gherdovich
AuthorDate:Thu, 12 Nov 2020 19:26:14 +01:00
iner's preference, I agree to either them adding
Signed-off-by: Giovanni Gherdovich
or to resend them the patch with a better commit message if they prefer.
Sorry for the inconvenience,
Giovanni Gherdovich
e:
> [...]
Hello Rafael,
I'd like to test this patch, as I have concerns on how it performs against the
current intel_pstate passive + HWP + schedutil (which leaves HWP.REQ.DESIRED
untouched).
I'll get results within a week. Do you mind holding back the merge until then?
Thanks!
Giovanni Gherdovich
On Fri, 2020-12-04 at 18:03 +0100, Giovanni Gherdovich wrote:
> Frequency invariant accounting calculations need the ratio
> freq_curr/freq_max, but freq_max is unknown as it depends on dynamic power
> allocation between cores: AMD EPYC CPUs implement "Core Performance Boost".
41.50 247.99
dbench4 151.97 161.87 157.08 158.10 158.06 153.73
kernbench 162.78 167.22 162.90 164.19 164.65 164.72
gitsource 133.65 139.00 133.04 134.43 134.18 134.32
Signed-off-by: Giovanni Gherdovich
Signed-off-by:
The following commit has been merged into the sched/core branch of tip:
Commit-ID: 46609527577d1def0af29ca5b56cffeeea771ada
Gitweb:
https://git.kernel.org/tip/46609527577d1def0af29ca5b56cffeeea771ada
Author:Giovanni Gherdovich
AuthorDate:Thu, 12 Nov 2020 19:26:13 +01:00
The following commit has been merged into the sched/core branch of tip:
Commit-ID: 24f326686c925a848d603a2c22f1f6ed1b7786e2
Gitweb:
https://git.kernel.org/tip/24f326686c925a848d603a2c22f1f6ed1b7786e2
Author:Giovanni Gherdovich
AuthorDate:Thu, 12 Nov 2020 19:26:14 +01:00
On Mon, 2020-11-16 at 15:07 +0800, kernel test robot wrote:
> Greeting,
>
> FYI, we noticed a -14.1% regression of
> phoronix-test-suite.stress-ng.SystemVMessagePassing.bogo_ops_s due to commit:
>
>
> commit: 2a0abc59699896f03bf6f16efb8a3a490511216f ("x86, sched: Add support
> for frequency in
On Tue, 2020-11-10 at 21:05 +0100, Giovanni Gherdovich wrote:
> v2 at https://lore.kernel.org/lkml/20201110183054.15883-1-ggherdov...@suse.cz/
>
> Changes wrt v2:
>
> - "code golf" on the function function init_freq_invariance_cppc().
> Make better use of
e, with the invariant schedutil
governor, a suitable baseline to evaluate a (still work-in-progress)
CPPC-based cpufreq driver for the AMD platform (see
https://lore.kernel.org/lkml/cover.1562781484.git.janakarajan.natara...@amd.com
if/when it will resubmitted.
Giovanni Gherdovich (2):
x86, sched: U
itional to
CONFIG_ACPI_CPPC_LIB, not just CONFIG_ACPI.
Signed-off-by: Nathan Fontenot
[ ggherdov...@suse.cz: made safe under CPU hotplug, edited changelog ]
Signed-off-by: Giovanni Gherdovich
---
arch/x86/include/asm/topology.h | 8
arch/x86/kernel/smpboot.c
mated ratio of average max'
[ 14.024036] smpboot: Estimated ratio of average max frequency by base
frequency (times 1024): 1289
Signed-off-by: Giovanni Gherdovich
---
arch/x86/kernel/smpboot.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel
41.50 247.99
dbench4 151.97 161.87 157.08 158.10 158.06 153.73
kernbench 162.78 167.22 162.90 164.19 164.65 164.72
gitsource 133.65 139.00 133.04 134.43 134.18 134.32
Signed-off-by: Giovanni Gherdovich
---
arch/x86/kernel/
On Tue, 2020-11-10 at 19:30 +0100, Giovanni Gherdovich wrote:
> v1 at https://lore.kernel.org/lkml/20201110083936.31994-1-ggherdov...@suse.cz/
>
> Changes wrt v1:
>
> - made initialization safe under CPU hotplug.
> The function init_freq_invariance_cppc now lets only the fir
initialized later in boot than when the frequency
invariant calculation is currently made, I had to create a callback
from the CPPC init code to do the calculation after we have CPPC
data.
Signed-off-by: Nathan Fontenot
[ ggherdov...@suse.cz: made safe under CPU hotplug ]
Signed-off-by: Giovanni
mated ratio of average max'
[ 14.024036] smpboot: Estimated ratio of average max frequency by base
frequency (times 1024): 1289
Signed-off-by: Giovanni Gherdovich
---
arch/x86/kernel/smpboot.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel
vernor, a suitable baseline to evaluate a (still work-in-progress)
CPPC-based cpufreq driver for the AMD platform (see
https://lore.kernel.org/lkml/cover.1562781484.git.janakarajan.natara...@amd.com
if/when it will resubmitted.
Giovanni Gherdovich (2):
x86, sched: Use midpoint of max_boost and
41.50 247.99
dbench4 151.97 161.87 157.08 158.10 158.06 153.73
kernbench 162.78 167.22 162.90 164.19 164.65 164.72
gitsource 133.65 139.00 133.04 134.43 134.18 134.32
Signed-off-by: Giovanni Gherdovich
---
arch/x86/kernel/
On Tue, 2020-11-10 at 10:49 +0100, Peter Zijlstra wrote:
> On Tue, Nov 10, 2020 at 09:39:34AM +0100, Giovanni Gherdovich wrote:
>
> > +#ifdef CONFIG_ACPI
> > +void init_freq_invariance_cppc(void)
> > +{
> > + init_freq_invariance(false, true);
> >
initialized later in boot than when the frequency
invariant calculation is currently made, I had to create a callback
from the CPPC init code to do the calculation after we have CPPC
data.
Signed-off-by: Nathan Fontenot
[ ggherdov...@suse.cz: made safe under CPU hotplug ]
Signed-off-by: Giovanni
41.50 247.99
dbench4 151.97 161.87 157.08 158.10 158.06 153.73
kernbench 162.78 167.22 162.90 164.19 164.65 164.72
gitsource 133.65 139.00 133.04 134.43 134.18 134.32
Signed-off-by: Giovanni Gherdovich
---
arch/x86/kernel/
v1 at https://lore.kernel.org/lkml/20201110083936.31994-1-ggherdov...@suse.cz/
Changes wrt v1:
- made initialization safe under CPU hotplug.
The function init_freq_invariance_cppc now lets only the first caller
into init_freq_invariance().
Giovanni Gherdovich (2):
x86, sched: Use midpoint
mated ratio of average max'
[ 14.024036] smpboot: Estimated ratio of average max frequency by base
frequency (times 1024): 1289
Signed-off-by: Giovanni Gherdovich
---
arch/x86/kernel/smpboot.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel
initialized later in boot than when the frequency
invariant calculation is currently made, I had to create a callback
from the CPPC init code to do the calculation after we have CPPC
data.
Signed-off-by: Nathan Fontenot
[ ggherdov...@suse.cz: cosmetic changes ]
Signed-off-by: Giovanni Gherdovich
mated ratio of average max'
[ 14.024036] smpboot: Estimated ratio of average max frequency by base
frequency (times 1024): 1289
Signed-off-by: Giovanni Gherdovich
---
arch/x86/kernel/smpboot.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel
41.50 247.99
dbench4 151.97 161.87 157.08 158.10 158.06 153.73
kernbench 162.78 167.22 162.90 164.19 164.65 164.72
gitsource 133.65 139.00 133.04 134.43 134.18 134.32
Signed-off-by: Giovanni Gherdovich
---
arch/x86/kernel/
series is to provide, with the invariant schedutil
governor, a suitable baseline to evaluate a (still work-in-progress)
CPPC-based cpufreq driver for the AMD platform (see
https://lore.kernel.org/lkml/cover.1562781484.git.janakarajan.natara...@amd.com
if/when it will resubmitted.
Giovanni Gherdovich (
On Thu, 2020-10-22 at 22:10 +0200, Giovanni Gherdovich wrote:
> [...]
> To read the tables:
>
> Tilde (~) means the result is the same as baseline (or, the ratio is close
> to 1). The double asterisk (**) is a visual aid and means the result is
> worse than baseline (higher or
Hello Peter, Rafael,
back in August I tested a v5.8 kernel adding Rafael's patches from v5.9 that
make schedutil and HWP works together, i.e. f6ebbcf08f37 ("cpufreq:
intel_pstate:
Implement passive mode with HWP enabled").
The main point I took from the exercise is that tbench (network benchmark
On Thu, 2020-10-22 at 10:46 +0200, Peter Zijlstra wrote:
> On Sun, May 31, 2020 at 08:24:51PM +0200, Giovanni Gherdovich wrote:
>
> Hi Giovanni!
>
> > +error:
> > + pr_warn("Scheduler frequency invariance went wobbly, disabling!\n");
> > + sch
irely dismissing your finding, just explaining why this analysis
hasn't been in my top priorities lately (plus, I've just returned from a 3
weeks vacation :). I'm curious too about what causes the test to go red, but
I'm not overly worried given the above context.
Thanks,
Giovanni Gherdovich
The following commit has been merged into the sched/core branch of tip:
Commit-ID: e2b0d619b400ae326f954a018a1d65d736c237c5
Gitweb:
https://git.kernel.org/tip/e2b0d619b400ae326f954a018a1d65d736c237c5
Author:Giovanni Gherdovich
AuthorDate:Sun, 31 May 2020 20:24:51 +02:00
The following commit has been merged into the sched/core branch of tip:
Commit-ID: f4291df103315a696f0b8c4f45ca8ae773c17441
Gitweb:
https://git.kernel.org/tip/f4291df103315a696f0b8c4f45ca8ae773c17441
Author:Giovanni Gherdovich
AuthorDate:Sun, 31 May 2020 20:24:53 +02:00
The following commit has been merged into the sched/core branch of tip:
Commit-ID: 51beea8862a3095559862df39554f05042e1195b
Gitweb:
https://git.kernel.org/tip/51beea8862a3095559862df39554f05042e1195b
Author:Giovanni Gherdovich
AuthorDate:Sun, 31 May 2020 20:24:52 +02:00
There may be CPUs that support turbo boost but don't declare any turbo
ratio, i.e. their MSR_TURBO_RATIO_LIMIT is all zeroes. In that condition
scale-invariant calculations can't be performed.
Signed-off-by: Giovanni Gherdovich
Suggested-by: Ricardo Neri
Fixes: 1567c3e3467c ("
nt code behind
CONFIG_X86_64 (special thanks to "kbuild test robot" ).
Signed-off-by: Giovanni Gherdovich
Signed-off-by: Peter Zijlstra (Intel)
Fixes: 1567c3e3467c ("x86, sched: Add support for frequency invariance")
---
arch/x86/include/asm/topology
Be defensive against the case where the processor reports a base_freq
larger than turbo_freq (the ratio would be zero).
Signed-off-by: Giovanni Gherdovich
Signed-off-by: Peter Zijlstra (Intel)
Fixes: 1567c3e3467c ("x86, sched: Add support for frequency invariance")
---
arch/
e too.
[1]
https://lore.kernel.org/lkml/CAHk-=wix+nt2yxtdpszh9u_s96mcnqa56gjfxy45mzc47yg...@mail.gmail.com/
[2] https://lore.kernel.org/lkml/20200422144055.18171-1-ggherdov...@suse.cz/
[3]
https://lore.kernel.org/lkml/20200424013222.ga26...@ranerica-svr.sc.intel.com/
Giovanni Gherdovich (3):
x86, sched:
On Mon, 2020-05-18 at 15:20 -0700, Ricardo Neri wrote:
> On Sat, May 02, 2020 at 04:25:00PM +0200, Giovanni Gherdovich wrote:
> > >
> > > I've changed the patch like so.. OK?
> > >
> > > (ok, perhaps I went a little overboard with the paranoia ;-)
On Fri, 2020-05-01 at 15:04 +0200, Peter Zijlstra wrote:
> On Tue, Apr 28, 2020 at 03:24:50PM +0200, Giovanni Gherdovich wrote:
> > There may be CPUs that support turbo boost but don't declare any turbo
> > ratio, i.e. their MSR_TURBO_RATIO_LIMIT is all zeroes. In that
On Fri, 2020-05-01 at 15:30 +0200, Peter Zijlstra wrote:
> On Tue, Apr 28, 2020 at 03:24:49PM +0200, Giovanni Gherdovich wrote:
> > The product mcnt * arch_max_freq_ratio could be zero if it overflows u64.
> >
> > For context, a large value for arch_max_freq_ratio would be 50
to do frequency
invariance (we skipped reading MSR_TURBO_RATIO_LIMIT at boot because turbo was
disabled at that timed).
This behavior was requested by reviewers in this thread:
https://lore.kernel.org/lkml/1906426.HDqaVa71mF@kreacher/
and implemented with 918229cdd5ab ("x86/intel_pstate: Handle runtime turbo
disablement/enablement in frequency invariance").
Thanks,
Giovanni Gherdovich
[3]
https://lore.kernel.org/lkml/20200424013222.ga26...@ranerica-svr.sc.intel.com/
Giovanni Gherdovich (2):
x86, sched: Prevent divisions by zero in frequency invariant
accounting
x86, sched: Bail out of frequency invariance if turbo frequency is
unknown
arch/x86/kernel/smpb
invariant
accounting: the feature relies on measures of the clock frequency done at
every scheduler tick, which need to be "fresh" to be at all meaningful.
Signed-off-by: Giovanni Gherdovich
Fixes: 1567c3e3467c ("x86, sched: Add support for frequency invariance")
---
There may be CPUs that support turbo boost but don't declare any turbo
ratio, i.e. their MSR_TURBO_RATIO_LIMIT is all zeroes. In that condition
scale-invariant calculations can't be performed.
Signed-off-by: Giovanni Gherdovich
Suggested-by: Ricardo Neri
Fixes: 1567c3e3467c ("
On Thu, 2019-10-03 at 19:53 +0200, Rafael J. Wysocki wrote:
> On Thursday, October 3, 2019 2:15:37 PM CEST Peter Zijlstra wrote:
> > On Thu, Oct 03, 2019 at 12:27:52PM +0200, Rafael J. Wysocki wrote:
> > > On Wednesday, October 2, 2019 2:29:25 PM CEST Giovanni Gherdovich wrot
On Fri, 2019-10-04 at 08:17 -0700, Srinivas Pandruvada wrote:
> On Fri, 2019-10-04 at 10:57 +0200, Giovanni Gherdovich wrote:
> > On Fri, 2019-10-04 at 10:29 +0200, Rafael J. Wysocki wrote:
> > > On Fri, Oct 4, 2019 at 10:24 AM Giovanni Gherdovich <
> > &
On Fri, 2019-10-04 at 10:29 +0200, Rafael J. Wysocki wrote:
> On Fri, Oct 4, 2019 at 10:24 AM Giovanni Gherdovich
> wrote:
> >
> > On Thu, 2019-10-03 at 20:31 -0700, Srinivas Pandruvada wrote:
> > > On Thu, 2019-10-03 at 20:05 +0200, Rafael J. Wysocki wrote:
>
On Thu, 2019-10-03 at 20:31 -0700, Srinivas Pandruvada wrote:
> On Thu, 2019-10-03 at 20:05 +0200, Rafael J. Wysocki wrote:
> > On Wednesday, October 2, 2019 2:29:26 PM CEST Giovanni Gherdovich
> > wrote:
> > > From: Srinivas Pandruvada
> > >
> > > in
ree,
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git , and depends on
5ebb34edbefa8 "x86/intel: Aggregate microserver naming".
I'll use '--base' in the future.
Giovanni
>
> url:
> https://github.com/0day-ci/linux/commits/Giovanni-Gherdovich/Add-supp
ench: https://www.postgresql.org/docs/10/pgbench.html
netperf: https://hewlettpackard.github.io/netperf/
dbench/tbench: https://dbench.samba.org/
gitsource: git unit test suite, github.com/git/git
NAS Parallel Benchmarks: https://www.nas.nasa.gov/publications/npb.html
hackbench: https://people.r
hould make easier to skim
through the content.
This submission incorporates the feedback and requests for additional tests
received during the presentation made at OSPM 2019 in Pisa three months ago.
[1]
https://lore.kernel.org/lkml/20180516044911.28797-2-srinivas.pandruv...@linux.intel.com/
Giovanni
nabled in
"passive" mode.
Signed-off-by: Srinivas Pandruvada
Signed-off-by: Giovanni Gherdovich
---
drivers/cpufreq/intel_pstate.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 9f02de9a1b47..c7d9149e99ee 100644
On Tue, 2019-09-24 at 18:00 +0200, Peter Zijlstra wrote:
> On Tue, Sep 24, 2019 at 04:03:32PM +0200, Peter Zijlstra wrote:
>
> > > I'll check what's the cost of static_cpu_has() and if it's non-negligible
> > > I'll
> > > do what you suggest (x86-specific version of arch_scale_freq_invariant().
>
On Tue, 2019-09-24 at 18:04 +0200, Peter Zijlstra wrote:
> On Mon, Sep 09, 2019 at 04:42:15AM +0200, Giovanni Gherdovich wrote:
>
> > +static void intel_set_cpu_max_freq(void)
> > +{
> > + /*
> > +* TODO: add support for:
> > +*
> > +* -
Hello Peter,
late replies as I wasn't in the office last week.
On Tue, 2019-09-24 at 18:30 +0200, Peter Zijlstra wrote:
> On Mon, Sep 09, 2019 at 04:42:15AM +0200, Giovanni Gherdovich wrote:
> > +static const struct x86_cpu_id has_turbo_ratio_group_limits[] =
Hello Quentin,
On Sat, 2019-09-14 at 12:57 +0200, Quentin Perret wrote:
> Hi Giovanni
>
> On Monday 09 Sep 2019 at 04:42:15 (+0200), Giovanni Gherdovich wrote:
> > +static inline long arch_scale_freq_capacity(int cpu)
> > +{
> > + if (static_cpu
Hello Srinivas,
On Fri, 2019-09-13 at 15:52 -0700, Srinivas Pandruvada wrote:
> On Mon, 2019-09-09 at 04:42 +0200, Giovanni Gherdovich wrote:
>
> ...
>
> > +
> > +/*
> > + * APERF/MPERF frequency ratio computation.
> > + *
> > + * The scheduler want
Hello Doug,
thanks for testing as usual, having some review on the experimental results is
really helpful. Sorry for the late reply as I'm traveling at the moment.
You raise really good points regarding pinning workloads on cpus, my comments
below.
On Wed, 2019-09-11 at 08:28 -0700, Doug Smythie
iant account is only enabled in
"passive" mode.
Signed-off-by: Srinivas Pandruvada
Signed-off-by: Giovanni Gherdovich
---
drivers/cpufreq/intel_pstate.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index cc27d
ench: https://www.postgresql.org/docs/10/pgbench.html
netperf: https://hewlettpackard.github.io/netperf/
dbench/tbench: https://dbench.samba.org/
gitsource: git unit test suite, github.com/git/git
NAS Parallel Benchmarks: https://www.nas.nasa.gov/publications/npb.html
hackbench: https://
//lore.kernel.org/lkml/20180516044911.28797-2-srinivas.pandruv...@linux.intel.com/
Giovanni Gherdovich (1):
x86,sched: Add support for frequency invariance
Srinivas Pandruvada (1):
cpufreq: intel_pstate: Conditional frequency invariant accounting
arch/x86/include/asm/topology.h | 29 +
Hello Doug,
sorry for the late reply, this week I was traveling.
First off, thank you for trying out MMTests; I admit the documentation is
somewhat incomplete. I'm going to give you an overview of how I run benchmarks
with MMTests and how do I print comparisons, hoping this can address your
quest
On Fri, 2018-11-23 at 11:35 +0100, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> The venerable menu governor does some thigns that are quite
> questionable in my view.
>
> First, it includes timer wakeups in the pattern detection data and
> mixes them up with wakeups from other sources
machine.
To raise an alert from the performance angle I have to see red on my board
from an entire category of benchmarks (ie I/O, or networking, or
scheduler-intensive, etc) and on a variety of hardware configurations. That's
not happening here.
On Sun, 2018-11-04 at 11:06 +0100, Rafae
On Sun, 2018-11-04 at 17:31 +0100, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> The venerable menu governor does some thigns that are quite
> questionable in my view. First, it includes timer wakeups in
> the pattern detection data and mixes them up with wakeups from
> other sources wh
fi
done
In practice the max number of clients I get is slightly below NUMCPUS*2 to
reach saturation. I write this as I read you ran it with 256 clients but I
never went that high.
>
> On 2018.10.31 11:36 Giovanni Gherdovich wrote:
>
> > Something I'd like to do
On Sun, 2018-11-04 at 11:06 +0100, Rafael J. Wysocki wrote:
> On Wednesday, October 31, 2018 7:36:21 PM CET Giovanni Gherdovich wrote:
>
> [...]
> You can use the cpu_idle trace point to correlate the selected state index
> with the observed idle duration (that's what Doug di
two.
After that it would be nice to somehow know where timers came from; i.e. if
I see that residences in a given state are consistently shorter than
they're supposed to be, it would be interesting to see who set the timer
that causes the wakeup. But... I'm not sure to know how to do that :) Do
you have a strategy to track down the origin of timers/interrupts? Is there
any script you're using to evaluate teo that you can share?
Thanks,
Giovanni Gherdovich
Hello Rafael,
I ran some benchmarks and will send you a detailed report later; for now I
have some questions to make sure I understand the code.
First off, I like your algorithm and you make an excellent job at
documenting it with comments. Since it's a heuristic, it's not "obvious"
code and comm
that behave that way, and the OS
is in a position to do something to mitigate the damage.
>
> > When unbound, the usage of individual cores appears low due to the
> > migrations. It may be intermittent usage as it context switches to
> > worker threads but it's not low utilisation either.
> >
> > intel_pstate also had logic for IO-boosting before HWP
>
> The IO-boosting logic of the intel_pstate governor has the same flaw as
> this unfortunately.
>
Again it's a matter of pragmatism. You'll find that another governor uses
IO-boosting: schedutil. And while intel_pstate needs it because it gets
otherwise killed by migrating tasks, schedutil is based on the PELT
utilization signal and doesn't have that problem at all. The principle there
is plain and simple: if I've been "wasting time" waiting on "slow" IO (disk),
that probably means I'm getting late and there is soon some compute to do:
better catch up on the lost time and speed up. IO-wait boosting on schedutil
was discussed at
https://lore.kernel.org/lkml/3752826.3sxaqiv...@vostro.rjw.lan/
Giovanni Gherdovich
SUSE Labs
y any value set is used somewhere.
>
> Waiting for test results from Mel Gorman, who is the original reporter.
> [SNIP]
Tested-by: Giovanni Gherdovich
This series has an overall positive performance impact on IO both on xfs and
ext4, and I'd be vary happy if it lands in v4.18. You dr
t of curiosity, do you see reasons for leaving some SKL out of the
default setting? Or maybe I'm missing something.
/proc/cpuinfo says that the model name is "Intel(R) Xeon(R) CPU E3-1240 v5";
the outputs of `cpuid -1` and `cpuid -1 --raw` are in this pastebin:
http://paste.opensuse.org/view/raw/34255499
Giovanni Gherdovich
SUSE Labs
on ext4
looks very promising. Good!
Later when I have it all I'll post my detailed results.
Giovanni Gherdovich
SUSE Labs
> v2
> This is a much simpler version than the previous one and only consider IO
> boost, using the existing mechanism. There is no change in this series
>
On Thu, 2016-09-01 at 12:29 +0200, Peter Zijlstra wrote:
> On Thu, Sep 01, 2016 at 12:07:34PM +0200, Stanislaw Gruszka wrote:
> >
> > On Thu, Sep 01, 2016 at 11:49:06AM +0200, Peter Zijlstra wrote:
> > >
> > > You're now making rather hot paths slower to benefit a rather
> > > slow path, that too
cpuclock monotonicity kept i.e. have
> problems fixed by above commits stay fixed, we also would like to have
> good performance.
>
> [... snip ...]
>
> Reported-and-tested-by: Giovanni Gherdovich
> Signed-off-by: Stanislaw Gruszka
> ---
> kernel/sc
1 - 100 of 109 matches
Mail list logo
