On Wed, Oct 02, 2019 at 02:25:52PM +0200, Giovanni Gherdovich wrote:
> > What about KABYLAKE_X and ICELAKE_X ?
>
> KABYLAKE_X: does it exist? I couldn't find it in
> arch/x86/include/asm/intel-family.h (the tip tree), I only see KABYLAKE_L and
> KABYLAKE.
My bad, I must've been staring cross-eye
On Wed, Oct 02, 2019 at 02:27:54PM +0200, Giovanni Gherdovich wrote:
> 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
>
On Wed, Oct 02, 2019 at 02:26:44PM +0200, Giovanni Gherdovich wrote:
> 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 supp
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:
> > +*
> > +* - Xeon Phi (KNM, KNL)
> > +* - Xeon Gold/Pla
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[] = {
> > + ICPU(INTEL_FAM6_ATOM_GOLDMO
On 2019.09.24 01:06 Mel Gorman wrote:
> On Thu, Sep 19, 2019 at 07:42:29AM -0700, Doug Smythies wrote:
>> On 2019.09.17 07:25 Giovanni Gherdovich wrote:
>>>On Wed, 2019-09-11 at 08:28 -0700, Doug Smythies wrote:
>>> [...]
>
> Hence, I think this patchset should be considered on its own merits.
A
On Mon, Sep 09, 2019 at 04:42:15AM +0200, Giovanni Gherdovich wrote:
> +static const struct x86_cpu_id has_turbo_ratio_group_limits[] = {
> + ICPU(INTEL_FAM6_ATOM_GOLDMONT),
> + ICPU(INTEL_FAM6_ATOM_GOLDMONT_X),
That's GOLDMONT_D in recent tip kernels.
> + ICPU(INTEL_FAM6_ATOM_GOLDMON
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:
> + *
> + * - Xeon Phi (KNM, KNL)
> + * - Xeon Gold/Platinum, Atom Goldmont/Goldmont Plus
> + * - Atom Silvermont
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().
>
> static_cpu_has() is an alternative and ends up being a static b
On Tue, Sep 17, 2019 at 04:27:46PM +0200, Giovanni Gherdovich wrote:
> 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 c
On Thu, Sep 19, 2019 at 07:42:29AM -0700, Doug Smythies wrote:
> On 2019.09.17 07:25 Giovanni Gherdovich wrote:
> >On Wed, 2019-09-11 at 08:28 -0700, Doug Smythies wrote:
> > [...]
>
> >> The problem with the test is its run to run variability, which was from
> >> all the disk I/O, as far as I cou
On Tue, 2019-09-17 at 16:27 +0200, Giovanni Gherdovich wrote:
> 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.
Hi Giovanni,
Thank you for your detailed reply.
On 2019.09.17 07:25 Giovanni Gherdovich wrote:
>On Wed, 2019-09-11 at 08:28 -0700, Doug Smythies wrote:
> [...]
>> The problem with the test is its run to run variability, which was from
>> all the disk I/O, as far as I could determine. At the time
On Tue, 17 Sep 2019 at 16:21, Giovanni Gherdovich wrote:
>
> 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.
> >
On Tuesday 17 Sep 2019 at 16:27:46 (+0200), Giovanni Gherdovich 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().
In case this is indeed expensive to check, you could always add a stat
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_has(X86_FEATURE_APERFMPERF))
> > + retu
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 wants to do frequency invariant accounting and
> >
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
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_has(X86_FEATURE_APERFMPERF))
> + return per_cpu(arch_cpu_freq, cpu);
So, if this is conditional, perhaps you could also
On Mon, 2019-09-09 at 04:42 +0200, Giovanni Gherdovich wrote:
...
> +
> +/*
> + * APERF/MPERF frequency ratio computation.
> + *
> + * The scheduler wants to do frequency invariant accounting and
> needs a <1
> + * ratio to account for the 'current' frequency, corresponding to
> + * freq_curr / f
On 2019.09.11 08:28 Doug Smythies wrote:
> Hi Giovanni,
>
> Thank you for the great detail and test results you provided.
>
> On 2019.09.08.07:42 Giovanni Gherdovich wrote:
>
> ... [snip]...
>
>> The test we call "gitsource" (running the git unit test suite, a long-running
>> single-threaded shell
Hi Giovanni,
Thank you for the great detail and test results you provided.
On 2019.09.08.07:42 Giovanni Gherdovich wrote:
... [snip]...
> The test we call "gitsource" (running the git unit test suite, a long-running
> single-threaded shell script) appears rather spectacular in this table (gains
Implement arch_scale_freq_capacity() for 'modern' x86. This function
is used by the scheduler to correctly account usage in the face of
DVFS.
The present patch addresses Intel processors specifically and has positive
performance and performance-per-watt implications for the schedutil cpufreq
gover
24 matches
Mail list logo