Hi Patrick,
Il 06/02/2018 19:36, Patrick Bellasi ha scritto:
On 06-Feb 19:14, Claudio Scordino wrote:
Hi Patrick,
At first glance, your proposal below makes to make sense.
However, I'm wondering if we cannot get it working using
rq->dl's provided information instead of flags?
Yes, we can
Hi Patrick,
Il 06/02/2018 19:36, Patrick Bellasi ha scritto:
On 06-Feb 19:14, Claudio Scordino wrote:
Hi Patrick,
At first glance, your proposal below makes to make sense.
However, I'm wondering if we cannot get it working using
rq->dl's provided information instead of flags?
Yes, we can
On 06-Feb 19:14, Claudio Scordino wrote:
> Hi Patrick,
> >At first glance, your proposal below makes to make sense.
> >
> >However, I'm wondering if we cannot get it working using
> >rq->dl's provided information instead of flags?
>
> Yes, we can use the value of rq->dl to check if there has
On 06-Feb 19:14, Claudio Scordino wrote:
> Hi Patrick,
> >At first glance, your proposal below makes to make sense.
> >
> >However, I'm wondering if we cannot get it working using
> >rq->dl's provided information instead of flags?
>
> Yes, we can use the value of rq->dl to check if there has
Hi Patrick,
Il 06/02/2018 16:43, Patrick Bellasi ha scritto:
Hi Claudio,
On 06-Feb 11:55, Claudio Scordino wrote:
Hi Peter,
Il 20/12/2017 16:30, Peter Zijlstra ha scritto:
So I ended up with the below (on top of Juri's cpufreq-dl patches).
It compiles, but that's about all the testing it
Hi Patrick,
Il 06/02/2018 16:43, Patrick Bellasi ha scritto:
Hi Claudio,
On 06-Feb 11:55, Claudio Scordino wrote:
Hi Peter,
Il 20/12/2017 16:30, Peter Zijlstra ha scritto:
So I ended up with the below (on top of Juri's cpufreq-dl patches).
It compiles, but that's about all the testing it
Hi Claudio,
On 06-Feb 11:55, Claudio Scordino wrote:
> Hi Peter,
>
> Il 20/12/2017 16:30, Peter Zijlstra ha scritto:
> >
> >So I ended up with the below (on top of Juri's cpufreq-dl patches).
> >
> >It compiles, but that's about all the testing it had.
> >
> >--- a/include/linux/sched/cpufreq.h
Hi Claudio,
On 06-Feb 11:55, Claudio Scordino wrote:
> Hi Peter,
>
> Il 20/12/2017 16:30, Peter Zijlstra ha scritto:
> >
> >So I ended up with the below (on top of Juri's cpufreq-dl patches).
> >
> >It compiles, but that's about all the testing it had.
> >
> >--- a/include/linux/sched/cpufreq.h
Hi Peter,
Il 20/12/2017 16:30, Peter Zijlstra ha scritto:
So I ended up with the below (on top of Juri's cpufreq-dl patches).
It compiles, but that's about all the testing it had.
--- a/include/linux/sched/cpufreq.h
+++ b/include/linux/sched/cpufreq.h
@@ -8,9 +8,7 @@
* Interface between
Hi Peter,
Il 20/12/2017 16:30, Peter Zijlstra ha scritto:
So I ended up with the below (on top of Juri's cpufreq-dl patches).
It compiles, but that's about all the testing it had.
--- a/include/linux/sched/cpufreq.h
+++ b/include/linux/sched/cpufreq.h
@@ -8,9 +8,7 @@
* Interface between
Hi Peter,
Il 31/12/2017 10:43, Claudio Scordino ha scritto:
Hi all,
Il 20/12/2017 16:56, Peter Zijlstra ha scritto:
On Wed, Dec 20, 2017 at 04:30:29PM +0100, Peter Zijlstra wrote:
So I ended up with the below (on top of Juri's cpufreq-dl patches).
It compiles, but that's about all the
Hi Peter,
Il 31/12/2017 10:43, Claudio Scordino ha scritto:
Hi all,
Il 20/12/2017 16:56, Peter Zijlstra ha scritto:
On Wed, Dec 20, 2017 at 04:30:29PM +0100, Peter Zijlstra wrote:
So I ended up with the below (on top of Juri's cpufreq-dl patches).
It compiles, but that's about all the
Hi all,
Il 20/12/2017 16:56, Peter Zijlstra ha scritto:
On Wed, Dec 20, 2017 at 04:30:29PM +0100, Peter Zijlstra wrote:
So I ended up with the below (on top of Juri's cpufreq-dl patches).
It compiles, but that's about all the testing it had.
Should all be available at:
Hi all,
Il 20/12/2017 16:56, Peter Zijlstra ha scritto:
On Wed, Dec 20, 2017 at 04:30:29PM +0100, Peter Zijlstra wrote:
So I ended up with the below (on top of Juri's cpufreq-dl patches).
It compiles, but that's about all the testing it had.
Should all be available at:
On 22/12/17 12:50, Patrick Bellasi wrote:
> On 22-Dec 13:43, Juri Lelli wrote:
> > On 22/12/17 12:38, Patrick Bellasi wrote:
> > > On 22-Dec 13:19, Peter Zijlstra wrote:
> > > > On Fri, Dec 22, 2017 at 12:07:37PM +, Patrick Bellasi wrote:
> > > > > > I was thinking that since dl is a 'global'
On 22/12/17 12:50, Patrick Bellasi wrote:
> On 22-Dec 13:43, Juri Lelli wrote:
> > On 22/12/17 12:38, Patrick Bellasi wrote:
> > > On 22-Dec 13:19, Peter Zijlstra wrote:
> > > > On Fri, Dec 22, 2017 at 12:07:37PM +, Patrick Bellasi wrote:
> > > > > > I was thinking that since dl is a 'global'
On 22-Dec 13:43, Juri Lelli wrote:
> On 22/12/17 12:38, Patrick Bellasi wrote:
> > On 22-Dec 13:19, Peter Zijlstra wrote:
> > > On Fri, Dec 22, 2017 at 12:07:37PM +, Patrick Bellasi wrote:
> > > > > I was thinking that since dl is a 'global' scheduler the reservation
> > > > > would be too and
On 22-Dec 13:43, Juri Lelli wrote:
> On 22/12/17 12:38, Patrick Bellasi wrote:
> > On 22-Dec 13:19, Peter Zijlstra wrote:
> > > On Fri, Dec 22, 2017 at 12:07:37PM +, Patrick Bellasi wrote:
> > > > > I was thinking that since dl is a 'global' scheduler the reservation
> > > > > would be too and
On 22/12/17 12:38, Patrick Bellasi wrote:
> On 22-Dec 13:19, Peter Zijlstra wrote:
> > On Fri, Dec 22, 2017 at 12:07:37PM +, Patrick Bellasi wrote:
> > > > I was thinking that since dl is a 'global' scheduler the reservation
> > > > would be too and thus the freq just needs a single CPU to be
On 22/12/17 12:38, Patrick Bellasi wrote:
> On 22-Dec 13:19, Peter Zijlstra wrote:
> > On Fri, Dec 22, 2017 at 12:07:37PM +, Patrick Bellasi wrote:
> > > > I was thinking that since dl is a 'global' scheduler the reservation
> > > > would be too and thus the freq just needs a single CPU to be
On 22-Dec 13:19, Peter Zijlstra wrote:
> On Fri, Dec 22, 2017 at 12:07:37PM +, Patrick Bellasi wrote:
> > > I was thinking that since dl is a 'global' scheduler the reservation
> > > would be too and thus the freq just needs a single CPU to be observed;
> >
> > AFAIU global is only the
On 22-Dec 13:19, Peter Zijlstra wrote:
> On Fri, Dec 22, 2017 at 12:07:37PM +, Patrick Bellasi wrote:
> > > I was thinking that since dl is a 'global' scheduler the reservation
> > > would be too and thus the freq just needs a single CPU to be observed;
> >
> > AFAIU global is only the
On 22/12/17 13:19, Peter Zijlstra wrote:
> On Fri, Dec 22, 2017 at 12:07:37PM +, Patrick Bellasi wrote:
> > > I was thinking that since dl is a 'global' scheduler the reservation
> > > would be too and thus the freq just needs a single CPU to be observed;
> >
> > AFAIU global is only the
On 22/12/17 13:19, Peter Zijlstra wrote:
> On Fri, Dec 22, 2017 at 12:07:37PM +, Patrick Bellasi wrote:
> > > I was thinking that since dl is a 'global' scheduler the reservation
> > > would be too and thus the freq just needs a single CPU to be observed;
> >
> > AFAIU global is only the
On 22-Dec 13:10, Peter Zijlstra wrote:
> On Fri, Dec 22, 2017 at 12:46:18PM +0100, Peter Zijlstra wrote:
> > Blergh that'd make a mess of things again.
>
> Something like so then..
>
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -187,11 +187,16 @@ static
On 22-Dec 13:10, Peter Zijlstra wrote:
> On Fri, Dec 22, 2017 at 12:46:18PM +0100, Peter Zijlstra wrote:
> > Blergh that'd make a mess of things again.
>
> Something like so then..
>
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -187,11 +187,16 @@ static
On Fri, Dec 22, 2017 at 12:14:45PM +, Patrick Bellasi wrote:
> I think that check is already gone for CFS in the current PeterZ tree.
> It seems we use TICK_NS just for the reset of iowait_boost, isn't it?
Easy enough to bring back though.
> However, if the remote updates of CFS works as
On Fri, Dec 22, 2017 at 12:14:45PM +, Patrick Bellasi wrote:
> I think that check is already gone for CFS in the current PeterZ tree.
> It seems we use TICK_NS just for the reset of iowait_boost, isn't it?
Easy enough to bring back though.
> However, if the remote updates of CFS works as
On Fri, Dec 22, 2017 at 12:07:37PM +, Patrick Bellasi wrote:
> > I was thinking that since dl is a 'global' scheduler the reservation
> > would be too and thus the freq just needs a single CPU to be observed;
>
> AFAIU global is only the admission control (which is something worth a
> thread
On Fri, Dec 22, 2017 at 12:07:37PM +, Patrick Bellasi wrote:
> > I was thinking that since dl is a 'global' scheduler the reservation
> > would be too and thus the freq just needs a single CPU to be observed;
>
> AFAIU global is only the admission control (which is something worth a
> thread
On 22-Dec 13:07, Juri Lelli wrote:
> Hi Peter,
>
> On 22/12/17 12:46, Peter Zijlstra wrote:
> > On Fri, Dec 22, 2017 at 11:02:06AM +, Patrick Bellasi wrote:
> > > > @@ -315,8 +315,8 @@ static unsigned int sugov_next_freq_shared(struct
> > > > sugov_cpu *sg_cpu, u64 time)
> > > >
On 22-Dec 13:07, Juri Lelli wrote:
> Hi Peter,
>
> On 22/12/17 12:46, Peter Zijlstra wrote:
> > On Fri, Dec 22, 2017 at 11:02:06AM +, Patrick Bellasi wrote:
> > > > @@ -315,8 +315,8 @@ static unsigned int sugov_next_freq_shared(struct
> > > > sugov_cpu *sg_cpu, u64 time)
> > > >
On Fri, Dec 22, 2017 at 12:46:18PM +0100, Peter Zijlstra wrote:
> Blergh that'd make a mess of things again.
Something like so then..
--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c
@@ -187,11 +187,16 @@ static void sugov_get_util(struct sugov_
static unsigned
On Fri, Dec 22, 2017 at 12:46:18PM +0100, Peter Zijlstra wrote:
> Blergh that'd make a mess of things again.
Something like so then..
--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c
@@ -187,11 +187,16 @@ static void sugov_get_util(struct sugov_
static unsigned
On 22-Dec 12:46, Peter Zijlstra wrote:
> On Fri, Dec 22, 2017 at 11:02:06AM +, Patrick Bellasi wrote:
> > > @@ -315,8 +315,8 @@ static unsigned int sugov_next_freq_shared(struct
> > > sugov_cpu *sg_cpu, u64 time)
> > > unsigned long j_util, j_max;
> > > s64 delta_ns;
> > >
On 22-Dec 12:46, Peter Zijlstra wrote:
> On Fri, Dec 22, 2017 at 11:02:06AM +, Patrick Bellasi wrote:
> > > @@ -315,8 +315,8 @@ static unsigned int sugov_next_freq_shared(struct
> > > sugov_cpu *sg_cpu, u64 time)
> > > unsigned long j_util, j_max;
> > > s64 delta_ns;
> > >
Hi Peter,
On 22/12/17 12:46, Peter Zijlstra wrote:
> On Fri, Dec 22, 2017 at 11:02:06AM +, Patrick Bellasi wrote:
> > > @@ -315,8 +315,8 @@ static unsigned int sugov_next_freq_shared(struct
> > > sugov_cpu *sg_cpu, u64 time)
> > > unsigned long j_util, j_max;
> > > s64
Hi Peter,
On 22/12/17 12:46, Peter Zijlstra wrote:
> On Fri, Dec 22, 2017 at 11:02:06AM +, Patrick Bellasi wrote:
> > > @@ -315,8 +315,8 @@ static unsigned int sugov_next_freq_shared(struct
> > > sugov_cpu *sg_cpu, u64 time)
> > > unsigned long j_util, j_max;
> > > s64
On Fri, Dec 22, 2017 at 11:02:06AM +, Patrick Bellasi wrote:
> > @@ -315,8 +315,8 @@ static unsigned int sugov_next_freq_shared(struct
> > sugov_cpu *sg_cpu, u64 time)
> > unsigned long j_util, j_max;
> > s64 delta_ns;
> >
> > - if (j_sg_cpu != sg_cpu)
> >
On Fri, Dec 22, 2017 at 11:02:06AM +, Patrick Bellasi wrote:
> > @@ -315,8 +315,8 @@ static unsigned int sugov_next_freq_shared(struct
> > sugov_cpu *sg_cpu, u64 time)
> > unsigned long j_util, j_max;
> > s64 delta_ns;
> >
> > - if (j_sg_cpu != sg_cpu)
> >
On 22-Dec 11:06, Peter Zijlstra wrote:
> On Wed, Dec 20, 2017 at 06:38:14PM +0100, Juri Lelli wrote:
> > On 20/12/17 16:30, Peter Zijlstra wrote:
> >
> > [...]
> >
> > > @@ -327,12 +331,7 @@ static unsigned int sugov_next_freq_shar
> > > if (delta_ns > TICK_NSEC) {
> > >
On 22-Dec 11:06, Peter Zijlstra wrote:
> On Wed, Dec 20, 2017 at 06:38:14PM +0100, Juri Lelli wrote:
> > On 20/12/17 16:30, Peter Zijlstra wrote:
> >
> > [...]
> >
> > > @@ -327,12 +331,7 @@ static unsigned int sugov_next_freq_shar
> > > if (delta_ns > TICK_NSEC) {
> > >
On Wed, Dec 20, 2017 at 06:38:14PM +0100, Juri Lelli wrote:
> On 20/12/17 16:30, Peter Zijlstra wrote:
>
> [...]
>
> > @@ -327,12 +331,7 @@ static unsigned int sugov_next_freq_shar
> > if (delta_ns > TICK_NSEC) {
> > j_sg_cpu->iowait_boost = 0;
> >
On Wed, Dec 20, 2017 at 06:38:14PM +0100, Juri Lelli wrote:
> On 20/12/17 16:30, Peter Zijlstra wrote:
>
> [...]
>
> > @@ -327,12 +331,7 @@ static unsigned int sugov_next_freq_shar
> > if (delta_ns > TICK_NSEC) {
> > j_sg_cpu->iowait_boost = 0;
> >
On Thu, Dec 21, 2017 at 04:13:17PM +0530, Viresh Kumar wrote:
> On 21-12-17, 11:39, Peter Zijlstra wrote:
> > The difference is that we apply the per-cpu boost on the per-cpu util
> > value and _then_ find the overall maximum.
> >
> > Instead of finding the overall maximum and then apply the
On Thu, Dec 21, 2017 at 04:13:17PM +0530, Viresh Kumar wrote:
> On 21-12-17, 11:39, Peter Zijlstra wrote:
> > The difference is that we apply the per-cpu boost on the per-cpu util
> > value and _then_ find the overall maximum.
> >
> > Instead of finding the overall maximum and then apply the
On 21-12-17, 11:39, Peter Zijlstra wrote:
> The difference is that we apply the per-cpu boost on the per-cpu util
> value and _then_ find the overall maximum.
>
> Instead of finding the overall maximum and then apply the per-cpu boost
> to that.
Okay, so it is just about the right sequencing of
On 21-12-17, 11:39, Peter Zijlstra wrote:
> The difference is that we apply the per-cpu boost on the per-cpu util
> value and _then_ find the overall maximum.
>
> Instead of finding the overall maximum and then apply the per-cpu boost
> to that.
Okay, so it is just about the right sequencing of
On Thu, Dec 21, 2017 at 04:00:22PM +0530, Viresh Kumar wrote:
> On 21-12-17, 11:25, Peter Zijlstra wrote:
> > On Thu, Dec 21, 2017 at 02:45:02PM +0530, Viresh Kumar wrote:
> > > On 20-12-17, 16:43, Peter Zijlstra wrote:
> > > > The below makes more sense to me too; hmm?
> > > >
> > > > @@ -335,12
On Thu, Dec 21, 2017 at 04:00:22PM +0530, Viresh Kumar wrote:
> On 21-12-17, 11:25, Peter Zijlstra wrote:
> > On Thu, Dec 21, 2017 at 02:45:02PM +0530, Viresh Kumar wrote:
> > > On 20-12-17, 16:43, Peter Zijlstra wrote:
> > > > The below makes more sense to me too; hmm?
> > > >
> > > > @@ -335,12
On 21-12-17, 11:25, Peter Zijlstra wrote:
> On Thu, Dec 21, 2017 at 02:45:02PM +0530, Viresh Kumar wrote:
> > On 20-12-17, 16:43, Peter Zijlstra wrote:
> > > The below makes more sense to me too; hmm?
> > >
> > > @@ -335,12 +335,11 @@ static unsigned int sugov_next_freq_shar
> > >
> > >
On 21-12-17, 11:25, Peter Zijlstra wrote:
> On Thu, Dec 21, 2017 at 02:45:02PM +0530, Viresh Kumar wrote:
> > On 20-12-17, 16:43, Peter Zijlstra wrote:
> > > The below makes more sense to me too; hmm?
> > >
> > > @@ -335,12 +335,11 @@ static unsigned int sugov_next_freq_shar
> > >
> > >
On Thu, Dec 21, 2017 at 02:45:02PM +0530, Viresh Kumar wrote:
> On 20-12-17, 16:43, Peter Zijlstra wrote:
> > The below makes more sense to me too; hmm?
> >
> > @@ -335,12 +335,11 @@ static unsigned int sugov_next_freq_shar
> >
> > j_max = j_sg_cpu->max;
> > j_util =
On Thu, Dec 21, 2017 at 02:45:02PM +0530, Viresh Kumar wrote:
> On 20-12-17, 16:43, Peter Zijlstra wrote:
> > The below makes more sense to me too; hmm?
> >
> > @@ -335,12 +335,11 @@ static unsigned int sugov_next_freq_shar
> >
> > j_max = j_sg_cpu->max;
> > j_util =
On 20-12-17, 16:43, Peter Zijlstra wrote:
> The below makes more sense to me too; hmm?
>
> @@ -335,12 +335,11 @@ static unsigned int sugov_next_freq_shar
>
> j_max = j_sg_cpu->max;
> j_util = sugov_aggregate_util(j_sg_cpu);
> +
On 20-12-17, 16:43, Peter Zijlstra wrote:
> The below makes more sense to me too; hmm?
>
> @@ -335,12 +335,11 @@ static unsigned int sugov_next_freq_shar
>
> j_max = j_sg_cpu->max;
> j_util = sugov_aggregate_util(j_sg_cpu);
> +
On 20-12-17, 16:30, Peter Zijlstra wrote:
>
> So I ended up with the below (on top of Juri's cpufreq-dl patches).
Nice :)
There are two things that I noticed in your tree.
Firstly, there is no need of the following patch as we shouldn't have
the problem mentioned in the commit anymore:
On 20-12-17, 16:30, Peter Zijlstra wrote:
>
> So I ended up with the below (on top of Juri's cpufreq-dl patches).
Nice :)
There are two things that I noticed in your tree.
Firstly, there is no need of the following patch as we shouldn't have
the problem mentioned in the commit anymore:
On Wed, Dec 20, 2017 at 06:38:14PM +0100, Juri Lelli wrote:
> On 20/12/17 16:30, Peter Zijlstra wrote:
>
> [...]
>
> > @@ -327,12 +331,7 @@ static unsigned int sugov_next_freq_shar
> > if (delta_ns > TICK_NSEC) {
> > j_sg_cpu->iowait_boost = 0;
> >
On Wed, Dec 20, 2017 at 06:38:14PM +0100, Juri Lelli wrote:
> On 20/12/17 16:30, Peter Zijlstra wrote:
>
> [...]
>
> > @@ -327,12 +331,7 @@ static unsigned int sugov_next_freq_shar
> > if (delta_ns > TICK_NSEC) {
> > j_sg_cpu->iowait_boost = 0;
> >
On 20/12/17 16:30, Peter Zijlstra wrote:
[...]
> @@ -327,12 +331,7 @@ static unsigned int sugov_next_freq_shar
> if (delta_ns > TICK_NSEC) {
> j_sg_cpu->iowait_boost = 0;
> j_sg_cpu->iowait_boost_pending = false;
> -
On 20/12/17 16:30, Peter Zijlstra wrote:
[...]
> @@ -327,12 +331,7 @@ static unsigned int sugov_next_freq_shar
> if (delta_ns > TICK_NSEC) {
> j_sg_cpu->iowait_boost = 0;
> j_sg_cpu->iowait_boost_pending = false;
> -
On Wed, Dec 20, 2017 at 04:30:29PM +0100, Peter Zijlstra wrote:
>
> So I ended up with the below (on top of Juri's cpufreq-dl patches).
>
> It compiles, but that's about all the testing it had.
Should all be available at:
git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git
On Wed, Dec 20, 2017 at 04:30:29PM +0100, Peter Zijlstra wrote:
>
> So I ended up with the below (on top of Juri's cpufreq-dl patches).
>
> It compiles, but that's about all the testing it had.
Should all be available at:
git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git
On Wed, Dec 20, 2017 at 04:30:29PM +0100, Peter Zijlstra wrote:
> @@ -314,6 +315,9 @@ static unsigned int sugov_next_freq_shar
> unsigned long j_util, j_max;
> s64 delta_ns;
>
> + if (j_sg_cpu != sg_cpu)
> + sugov_get_util(j_sg_cpu);
>
On Wed, Dec 20, 2017 at 04:30:29PM +0100, Peter Zijlstra wrote:
> @@ -314,6 +315,9 @@ static unsigned int sugov_next_freq_shar
> unsigned long j_util, j_max;
> s64 delta_ns;
>
> + if (j_sg_cpu != sg_cpu)
> + sugov_get_util(j_sg_cpu);
>
So I ended up with the below (on top of Juri's cpufreq-dl patches).
It compiles, but that's about all the testing it had.
--- a/include/linux/sched/cpufreq.h
+++ b/include/linux/sched/cpufreq.h
@@ -8,9 +8,7 @@
* Interface between cpufreq drivers and the scheduler:
*/
-#define
So I ended up with the below (on top of Juri's cpufreq-dl patches).
It compiles, but that's about all the testing it had.
--- a/include/linux/sched/cpufreq.h
+++ b/include/linux/sched/cpufreq.h
@@ -8,9 +8,7 @@
* Interface between cpufreq drivers and the scheduler:
*/
-#define
68 matches
Mail list logo
