d_create");
}
pthread_exit(NULL);
return 0;
}
END pound_clock_gettime.c
Signed-off-by: Mike Galbraith <mgalbra...@suse.de>
Signed-off-by: Giovanni Gherdovich <ggherdov...@suse.cz>
---
kernel/sched/core.c | 4
1 file changed, 4 insertio
l:https://github.com/0day-ci/linux/commits/Giovanni-Gherdovich/
> sched-cputime-Mitigate-performance-regression-in-times
> -clock_gettime/20160726-221216
> config: mips-allyesconfig (attached as .config)
> compiler: mips-linux-gnu-gcc (Debian 5.4.0-6) 5.4.0 20160609
> reproduce:
>
Hello Peter,
thank you for your reply.
On Tue, 2016-08-02 at 12:37 +0200, Peter Zijlstra wrote:
> On Tue, Jul 26, 2016 at 04:07:14PM +0200, Giovanni Gherdovich wrote:
>
> > Signed-off-by: Mike Galbraith <mgalbra...@suse.de>
> > Signed-off-by: Giovanni Gherdovich <gg
-13.93%)
1102.95 ( 0.00%)6.46 (-119.00%) 3.81 (-29.24%)
3.38 (-14.69%)
1283.05 ( 0.00%)6.42 (-110.08%) 3.88 (-27.04%)
3.38 (-10.70%)
Regards,
Giovanni Gherdovich
Hello Stanislaw,
On Fri, 2016-08-12 at 14:10 +0200, Stanislaw Gruszka wrote:
>
> I measured (partial) revert performance on 4.7 using mmtest instructions
> from Giovanni and also tested some other possible fix (draft version):
>
> diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
>
pthread_exit(NULL);
}
int main()
{
pthread_t th[NUM_THREADS];
long rc, i;
pid_t pgid;
for (i = 0; i < NUM_THREADS; i++) {
rc = pthread_create([i], NULL, pound, (void *)i);
if (rc < 0)
perror("pt
-by chain
* added comment as per why the prefetches are needed
Giovanni Gherdovich (1):
sched/cputime: Mitigate performance regression in
times()/clock_gettime()
kernel/sched/core.c | 19 +++
1 file changed, 19 insertions(+)
--
2.6.6
On Wed, 2016-08-03 at 12:02 +0200, Peter Zijlstra wrote:
> On Wed, Aug 03, 2016 at 12:04:52AM +0200, Giovanni Gherdovich wrote:
>
> > > > +#if defined(CONFIG_FAIR_GROUP_SCHED)
> > >
> > > This here wants a comment on why we're doing this. Because I'm
>
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
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 <ggherdov...@suse.cz>
> Signed-off-by: St
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
> beyond intel_pstat
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
way 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 dropped
>
> > 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
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
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
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&
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
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
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
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/
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
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 ++
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
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
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 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
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
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
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
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
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");
> >
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,
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
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
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
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
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
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);
> >
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
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
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
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
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
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
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".
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
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.
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 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 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
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 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
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
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
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
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 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
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
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
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
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 ;-)
&
.
[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
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/
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
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[] = {
>
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:
> > +*
> > +* -
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().
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
/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
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
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 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 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, 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
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
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
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
[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
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
>
> > 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
way 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 dropped
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
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
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
> beyond intel_pstat
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
1 - 100 of 132 matches
Mail list logo
