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
frequency 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.
Thank
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
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
ate")
> Link:
> https://www.phoronix.com/scan.php?page=article=linux511-amd-schedutil=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: Rafael J. Wysocki
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
d: 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 Larabel
Signed-off-by: Giovanni Gherdovich
---
drivers/cpufreq/acpi-cpu
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.
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
d: 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: Giovanni Gherdovich
---
drivers/cpufreq/acpi-cpufreq.c | 64 ++
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
d: 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 Gherdovich
---
drivers/cpufreq/freq_table.c | 51
include/
d: 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 Gherdovich
---
drivers/cpufreq/freq_table.c | 51
include/
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
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
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".
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: Peter
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
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
nvariant 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: Use midpoint of
onditional 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
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/smpboot.c
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/smpbo
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 onl
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
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/smpboot.c
ble 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 max_P for frequ
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/smpbo
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
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/smpbo
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
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/smpboot.c
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
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/smpboot.c
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/smpbo
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 (2):
x86,
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
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
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");
> >
g 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 ("x86, sched
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.h | 2 +-
arc
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/
.
[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: check
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 cond
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
o 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
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")
---
arch/x86/k
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 ("x86, sched
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
/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-support-for-frequency-invaria
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.redhat.com/mingo/cfs-scheduler/tools/hackbench.c
Suggested-by: Peter Zijlstra
Signed-off-by: Giovanni Gh
he 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 Gherdovich (1):
x86,sched: A
y 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 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
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
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
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.redhat.com/mingo/cfs-scheduler/tools/hackbench.c
Suggested-by: Peter Zijlstra
Signed-off-by: Gio
11.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 +++
arch/x86/kernel/smpboot.c
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
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
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
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
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, Rafael J. Wysocki wrote:
> On Wednesday, October 31, 2018 7:36:21 PM CET Giov
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, Rafael J. Wysocki wrote:
> On Wednesday, October 31, 2018 7:36:21 PM CET Giov
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
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
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 now is verify that "teo&
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 now is verify that "teo&
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 d
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 d
hat 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
hat 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
1 - 100 of 132 matches
Mail list logo
