Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On Wed, Dec 20, 2017 at 06:27:17PM +0100, Juri Lelli wrote: > Thanks Peter for taking the patches. I was actually waiting for the flag > thing to be resolved to post again. :/ Yeah, I took them because it made sorting that easier, n/p.

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On Wed, Dec 20, 2017 at 06:27:17PM +0100, Juri Lelli wrote: > Thanks Peter for taking the patches. I was actually waiting for the flag > thing to be resolved to post again. :/ Yeah, I took them because it made sorting that easier, n/p.

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On 20/12/17 15:47, Rafael J. Wysocki wrote: > On Wednesday, December 20, 2017 2:28:26 PM CET Peter Zijlstra wrote: > > On Wed, Dec 20, 2017 at 12:55:46PM +, Patrick Bellasi wrote: > > > On 20-Dec 09:31, Peter Zijlstra wrote: > > > > > > Didn't juri have patches to make DL do something sane?

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On 20/12/17 15:47, Rafael J. Wysocki wrote: > On Wednesday, December 20, 2017 2:28:26 PM CET Peter Zijlstra wrote: > > On Wed, Dec 20, 2017 at 12:55:46PM +, Patrick Bellasi wrote: > > > On 20-Dec 09:31, Peter Zijlstra wrote: > > > > > > Didn't juri have patches to make DL do something sane?

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On 20-Dec 15:52, Rafael J. Wysocki wrote: > On Wednesday, December 20, 2017 3:31:00 PM CET Patrick Bellasi wrote: > > On 20-Dec 14:28, Peter Zijlstra wrote: > > > On Wed, Dec 20, 2017 at 12:55:46PM +, Patrick Bellasi wrote: > > > > On 20-Dec 09:31, Peter Zijlstra wrote: > > > > > > > > Didn't

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On 20-Dec 15:52, Rafael J. Wysocki wrote: > On Wednesday, December 20, 2017 3:31:00 PM CET Patrick Bellasi wrote: > > On 20-Dec 14:28, Peter Zijlstra wrote: > > > On Wed, Dec 20, 2017 at 12:55:46PM +, Patrick Bellasi wrote: > > > > On 20-Dec 09:31, Peter Zijlstra wrote: > > > > > > > > Didn't

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On Wednesday, December 20, 2017 3:31:00 PM CET Patrick Bellasi wrote: > On 20-Dec 14:28, Peter Zijlstra wrote: > > On Wed, Dec 20, 2017 at 12:55:46PM +, Patrick Bellasi wrote: > > > On 20-Dec 09:31, Peter Zijlstra wrote: > > > > > > Didn't juri have patches to make DL do something sane? But

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On Wednesday, December 20, 2017 3:31:00 PM CET Patrick Bellasi wrote: > On 20-Dec 14:28, Peter Zijlstra wrote: > > On Wed, Dec 20, 2017 at 12:55:46PM +, Patrick Bellasi wrote: > > > On 20-Dec 09:31, Peter Zijlstra wrote: > > > > > > Didn't juri have patches to make DL do something sane? But

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On Wed, Dec 20, 2017 at 03:47:23PM +0100, Rafael J. Wysocki wrote: > > Well, we still need flags for crap like IO-WAIT IIRC. That's sugov > > internal state and not something the scheduler actually already knows. > > Not only sugov to be precise, but yes. Oh, right, intel_pstate also consumes

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On Wed, Dec 20, 2017 at 03:47:23PM +0100, Rafael J. Wysocki wrote: > > Well, we still need flags for crap like IO-WAIT IIRC. That's sugov > > internal state and not something the scheduler actually already knows. > > Not only sugov to be precise, but yes. Oh, right, intel_pstate also consumes

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On Wednesday, December 20, 2017 2:28:26 PM CET Peter Zijlstra wrote: > On Wed, Dec 20, 2017 at 12:55:46PM +, Patrick Bellasi wrote: > > On 20-Dec 09:31, Peter Zijlstra wrote: > > > > Didn't juri have patches to make DL do something sane? But yes, I think > > > those flags are part of the

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On Wednesday, December 20, 2017 2:28:26 PM CET Peter Zijlstra wrote: > On Wed, Dec 20, 2017 at 12:55:46PM +, Patrick Bellasi wrote: > > On 20-Dec 09:31, Peter Zijlstra wrote: > > > > Didn't juri have patches to make DL do something sane? But yes, I think > > > those flags are part of the

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On 20-Dec 14:28, Peter Zijlstra wrote: > On Wed, Dec 20, 2017 at 12:55:46PM +, Patrick Bellasi wrote: > > On 20-Dec 09:31, Peter Zijlstra wrote: > > > > Didn't juri have patches to make DL do something sane? But yes, I think > > > those flags are part of the problem. > > > > He recently

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On 20-Dec 14:28, Peter Zijlstra wrote: > On Wed, Dec 20, 2017 at 12:55:46PM +, Patrick Bellasi wrote: > > On 20-Dec 09:31, Peter Zijlstra wrote: > > > > Didn't juri have patches to make DL do something sane? But yes, I think > > > those flags are part of the problem. > > > > He recently

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On Wed, Dec 20, 2017 at 12:55:46PM +, Patrick Bellasi wrote: > On 20-Dec 09:31, Peter Zijlstra wrote: > > Didn't juri have patches to make DL do something sane? But yes, I think > > those flags are part of the problem. > > He recently reposted them here: > >

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On Wed, Dec 20, 2017 at 12:55:46PM +, Patrick Bellasi wrote: > On 20-Dec 09:31, Peter Zijlstra wrote: > > Didn't juri have patches to make DL do something sane? But yes, I think > > those flags are part of the problem. > > He recently reposted them here: > >

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On 20-Dec 09:31, Peter Zijlstra wrote: > On Wed, Dec 20, 2017 at 09:34:46AM +0530, Viresh Kumar wrote: > > On 19-12-17, 20:25, Peter Zijlstra wrote: > > > Yeah, not happy about this either; we had code that did the right thing > > > without this extra tracking I think. > > > > Sure, but how do

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On 20-Dec 09:31, Peter Zijlstra wrote: > On Wed, Dec 20, 2017 at 09:34:46AM +0530, Viresh Kumar wrote: > > On 19-12-17, 20:25, Peter Zijlstra wrote: > > > Yeah, not happy about this either; we had code that did the right thing > > > without this extra tracking I think. > > > > Sure, but how do

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On Wed, Dec 20, 2017 at 02:18:59PM +0530, Viresh Kumar wrote: > On 20-12-17, 09:31, Peter Zijlstra wrote: > What about this case: A CFS task is running currently and an RT task > is enqueued. > > - Is it always the case that the CFS task is preempted immediately and > the CPU is given to RT

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On Wed, Dec 20, 2017 at 02:18:59PM +0530, Viresh Kumar wrote: > On 20-12-17, 09:31, Peter Zijlstra wrote: > What about this case: A CFS task is running currently and an RT task > is enqueued. > > - Is it always the case that the CFS task is preempted immediately and > the CPU is given to RT

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On 20-12-17, 09:31, Peter Zijlstra wrote: > On Wed, Dec 20, 2017 at 09:34:46AM +0530, Viresh Kumar wrote: > Please use the normal link format: > > https://lkml.kernel.org/r/$MSGID > > Then I can find them without having to resort to a frigging browser > thing. Sure, and that would be much

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On 20-12-17, 09:31, Peter Zijlstra wrote: > On Wed, Dec 20, 2017 at 09:34:46AM +0530, Viresh Kumar wrote: > Please use the normal link format: > > https://lkml.kernel.org/r/$MSGID > > Then I can find them without having to resort to a frigging browser > thing. Sure, and that would be much

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On Wed, Dec 20, 2017 at 09:34:46AM +0530, Viresh Kumar wrote: > On 19-12-17, 20:25, Peter Zijlstra wrote: > > Yeah, not happy about this either; we had code that did the right thing > > without this extra tracking I think. > > Sure, but how do you suggest we fix the problems we are facing with >

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On Wed, Dec 20, 2017 at 09:34:46AM +0530, Viresh Kumar wrote: > On 19-12-17, 20:25, Peter Zijlstra wrote: > > Yeah, not happy about this either; we had code that did the right thing > > without this extra tracking I think. > > Sure, but how do you suggest we fix the problems we are facing with >

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On 19-12-17, 20:25, Peter Zijlstra wrote: > Yeah, not happy about this either; we had code that did the right thing > without this extra tracking I think. Sure, but how do you suggest we fix the problems we are facing with the current design? Patrick had a completely different proposal for

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On 19-12-17, 20:25, Peter Zijlstra wrote: > Yeah, not happy about this either; we had code that did the right thing > without this extra tracking I think. Sure, but how do you suggest we fix the problems we are facing with the current design? Patrick had a completely different proposal for

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On Wed, Dec 13, 2017 at 03:23:21PM +0530, Viresh Kumar wrote: > Currently the schedutil governor overwrites the sg_cpu->flags field on > every call to the utilization handler. It was pretty good as the initial > implementation of utilization handlers, there are several drawbacks > though. > > The

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On Wed, Dec 13, 2017 at 03:23:21PM +0530, Viresh Kumar wrote: > Currently the schedutil governor overwrites the sg_cpu->flags field on > every call to the utilization handler. It was pretty good as the initial > implementation of utilization handlers, there are several drawbacks > though. > > The

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On Tuesday, December 19, 2017 4:41:18 AM CET Viresh Kumar wrote: > On 18-12-17, 19:30, Joel Fernandes wrote: > > Yes that's clean to me but then as Rafael said, the use of this flag > > will be too specific for schedutil-only sg_cpu->flags clearing purpose > > right? > > And so would be the extra

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On Tuesday, December 19, 2017 4:41:18 AM CET Viresh Kumar wrote: > On 18-12-17, 19:30, Joel Fernandes wrote: > > Yes that's clean to me but then as Rafael said, the use of this flag > > will be too specific for schedutil-only sg_cpu->flags clearing purpose > > right? > > And so would be the extra

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On 18-12-17, 19:30, Joel Fernandes wrote: > Yes that's clean to me but then as Rafael said, the use of this flag > will be too specific for schedutil-only sg_cpu->flags clearing purpose > right? And so would be the extra parameter ? -- viresh

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On 18-12-17, 19:30, Joel Fernandes wrote: > Yes that's clean to me but then as Rafael said, the use of this flag > will be too specific for schedutil-only sg_cpu->flags clearing purpose > right? And so would be the extra parameter ? -- viresh

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On Mon, Dec 18, 2017 at 7:26 PM, Viresh Kumar wrote: > On 19-12-17, 08:52, Viresh Kumar wrote: >> On 18-12-17, 19:18, Joel Fernandes wrote: >> > Hi Viresh, >> > >> > On Mon, Dec 18, 2017 at 7:12 PM, Viresh Kumar >> > wrote: >> > > On 18-12-17,

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On Mon, Dec 18, 2017 at 7:26 PM, Viresh Kumar wrote: > On 19-12-17, 08:52, Viresh Kumar wrote: >> On 18-12-17, 19:18, Joel Fernandes wrote: >> > Hi Viresh, >> > >> > On Mon, Dec 18, 2017 at 7:12 PM, Viresh Kumar >> > wrote: >> > > On 18-12-17, 12:14, Patrick Bellasi wrote: >> > >> For example,

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On 19-12-17, 08:52, Viresh Kumar wrote: > On 18-12-17, 19:18, Joel Fernandes wrote: > > Hi Viresh, > > > > On Mon, Dec 18, 2017 at 7:12 PM, Viresh Kumar > > wrote: > > > On 18-12-17, 12:14, Patrick Bellasi wrote: > > >> For example, swithing from: > > >> > > >> - void

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On 19-12-17, 08:52, Viresh Kumar wrote: > On 18-12-17, 19:18, Joel Fernandes wrote: > > Hi Viresh, > > > > On Mon, Dec 18, 2017 at 7:12 PM, Viresh Kumar > > wrote: > > > On 18-12-17, 12:14, Patrick Bellasi wrote: > > >> For example, swithing from: > > >> > > >> - void (*func)(struct

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On 18-12-17, 19:18, Joel Fernandes wrote: > Hi Viresh, > > On Mon, Dec 18, 2017 at 7:12 PM, Viresh Kumar wrote: > > On 18-12-17, 12:14, Patrick Bellasi wrote: > >> For example, swithing from: > >> > >> - void (*func)(struct update_util_data *data, u64 time, > >> -

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On 18-12-17, 19:18, Joel Fernandes wrote: > Hi Viresh, > > On Mon, Dec 18, 2017 at 7:12 PM, Viresh Kumar wrote: > > On 18-12-17, 12:14, Patrick Bellasi wrote: > >> For example, swithing from: > >> > >> - void (*func)(struct update_util_data *data, u64 time, > >> - unsigned int

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

Hi Viresh, On Mon, Dec 18, 2017 at 7:12 PM, Viresh Kumar wrote: > On 18-12-17, 12:14, Patrick Bellasi wrote: >> For example, swithing from: >> >> - void (*func)(struct update_util_data *data, u64 time, >> - unsigned int flags)) >> + void (*func)(struct

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

Hi Viresh, On Mon, Dec 18, 2017 at 7:12 PM, Viresh Kumar wrote: > On 18-12-17, 12:14, Patrick Bellasi wrote: >> For example, swithing from: >> >> - void (*func)(struct update_util_data *data, u64 time, >> - unsigned int flags)) >> + void (*func)(struct update_util_data *data, u64

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On 18-12-17, 12:14, Patrick Bellasi wrote: > For example, swithing from: > > - void (*func)(struct update_util_data *data, u64 time, > - unsigned int flags)) > + void (*func)(struct update_util_data *data, u64 time, > + unsigned int flags, bool set)) > > Where the

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On 18-12-17, 12:14, Patrick Bellasi wrote: > For example, swithing from: > > - void (*func)(struct update_util_data *data, u64 time, > - unsigned int flags)) > + void (*func)(struct update_util_data *data, u64 time, > + unsigned int flags, bool set)) > > Where the

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On Mon, Dec 18, 2017 at 12:59 PM, Viresh Kumar wrote: > On 18-12-17, 12:35, Rafael J. Wysocki wrote: >> Well, if SCHED_CPUFRREQ_CLEAR means "this CPU is going to enter the >> idle loop" really, then it is better to call it >> SCHED_CPUFRREQ_ENTER_IDLE, for example. >> >>

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On Mon, Dec 18, 2017 at 12:59 PM, Viresh Kumar wrote: > On 18-12-17, 12:35, Rafael J. Wysocki wrote: >> Well, if SCHED_CPUFRREQ_CLEAR means "this CPU is going to enter the >> idle loop" really, then it is better to call it >> SCHED_CPUFRREQ_ENTER_IDLE, for example. >> >> SCHED_CPUFRREQ_CLEAR

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On 18-Dec 17:29, Viresh Kumar wrote: > On 18-12-17, 12:35, Rafael J. Wysocki wrote: > > Well, if SCHED_CPUFRREQ_CLEAR means "this CPU is going to enter the > > idle loop" really, then it is better to call it > > SCHED_CPUFRREQ_ENTER_IDLE, for example. > > > > SCHED_CPUFRREQ_CLEAR meaning

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On 18-Dec 17:29, Viresh Kumar wrote: > On 18-12-17, 12:35, Rafael J. Wysocki wrote: > > Well, if SCHED_CPUFRREQ_CLEAR means "this CPU is going to enter the > > idle loop" really, then it is better to call it > > SCHED_CPUFRREQ_ENTER_IDLE, for example. > > > > SCHED_CPUFRREQ_CLEAR meaning

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On 18-12-17, 12:35, Rafael J. Wysocki wrote: > Well, if SCHED_CPUFRREQ_CLEAR means "this CPU is going to enter the > idle loop" really, then it is better to call it > SCHED_CPUFRREQ_ENTER_IDLE, for example. > > SCHED_CPUFRREQ_CLEAR meaning basically "you should clear these flags > now" doesn't

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On 18-12-17, 12:35, Rafael J. Wysocki wrote: > Well, if SCHED_CPUFRREQ_CLEAR means "this CPU is going to enter the > idle loop" really, then it is better to call it > SCHED_CPUFRREQ_ENTER_IDLE, for example. > > SCHED_CPUFRREQ_CLEAR meaning basically "you should clear these flags > now" doesn't

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On Mon, Dec 18, 2017 at 5:59 AM, Viresh Kumar wrote: > On 17-12-17, 01:19, Rafael J. Wysocki wrote: >> We can do that in principle, but why should it return early? Maybe it's >> a good time to update things, incidentally? >> >> I actually don't like the

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On Mon, Dec 18, 2017 at 5:59 AM, Viresh Kumar wrote: > On 17-12-17, 01:19, Rafael J. Wysocki wrote: >> We can do that in principle, but why should it return early? Maybe it's >> a good time to update things, incidentally? >> >> I actually don't like the SCHED_CPUFRREQ_CLEAR flag *concept* as it

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On 17-12-17, 01:19, Rafael J. Wysocki wrote: > We can do that in principle, but why should it return early? Maybe it's > a good time to update things, incidentally? > > I actually don't like the SCHED_CPUFRREQ_CLEAR flag *concept* as it is very > much specific to schedutil and blatantly ignores

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On 17-12-17, 01:19, Rafael J. Wysocki wrote: > We can do that in principle, but why should it return early? Maybe it's > a good time to update things, incidentally? > > I actually don't like the SCHED_CPUFRREQ_CLEAR flag *concept* as it is very > much specific to schedutil and blatantly ignores

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On Saturday, December 16, 2017 5:47:07 PM CET Viresh Kumar wrote: > On 16 December 2017 at 22:10, Rafael J. Wysocki wrote: > > On Wed, Dec 13, 2017 at 10:53 AM, Viresh Kumar > > wrote: > > >> +#define SCHED_CPUFREQ_CLEAR(1U << 31) > > > > I'm not

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On Saturday, December 16, 2017 5:47:07 PM CET Viresh Kumar wrote: > On 16 December 2017 at 22:10, Rafael J. Wysocki wrote: > > On Wed, Dec 13, 2017 at 10:53 AM, Viresh Kumar > > wrote: > > >> +#define SCHED_CPUFREQ_CLEAR(1U << 31) > > > > I'm not thrilled by this, because schedutil is not

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On 16 December 2017 at 22:10, Rafael J. Wysocki wrote: > On Wed, Dec 13, 2017 at 10:53 AM, Viresh Kumar > wrote: >> +#define SCHED_CPUFREQ_CLEAR(1U << 31) > > I'm not thrilled by this, because schedutil is not the only user of > the flags and

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On 16 December 2017 at 22:10, Rafael J. Wysocki wrote: > On Wed, Dec 13, 2017 at 10:53 AM, Viresh Kumar > wrote: >> +#define SCHED_CPUFREQ_CLEAR(1U << 31) > > I'm not thrilled by this, because schedutil is not the only user of > the flags and it's totally unclear what the other user(s)

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On Wed, Dec 13, 2017 at 10:53 AM, Viresh Kumar wrote: > Currently the schedutil governor overwrites the sg_cpu->flags field on > every call to the utilization handler. It was pretty good as the initial > implementation of utilization handlers, there are several drawbacks

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On Wed, Dec 13, 2017 at 10:53 AM, Viresh Kumar wrote: > Currently the schedutil governor overwrites the sg_cpu->flags field on > every call to the utilization handler. It was pretty good as the initial > implementation of utilization handlers, there are several drawbacks > though. > > The biggest

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On 13-12-17, 12:26, Juri Lelli wrote: > This flag doesn't do much, does it? I mean RT/DL/IOWAIT are used to bump > up frequency, while you are adding CFS for the sake of simmetry, right? > And with my patches DL will hopefully soon be in the same situation. > If my understanding is correct, maybe

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On 13-12-17, 12:26, Juri Lelli wrote: > This flag doesn't do much, does it? I mean RT/DL/IOWAIT are used to bump > up frequency, while you are adding CFS for the sake of simmetry, right? > And with my patches DL will hopefully soon be in the same situation. > If my understanding is correct, maybe

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

Hi Viresh, On 13/12/17 15:23, Viresh Kumar wrote: > Currently the schedutil governor overwrites the sg_cpu->flags field on > every call to the utilization handler. It was pretty good as the initial > implementation of utilization handlers, there are several drawbacks > though. > > The biggest

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

Hi Viresh, On 13/12/17 15:23, Viresh Kumar wrote: > Currently the schedutil governor overwrites the sg_cpu->flags field on > every call to the utilization handler. It was pretty good as the initial > implementation of utilization handlers, there are several drawbacks > though. > > The biggest

[PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

Currently the schedutil governor overwrites the sg_cpu->flags field on every call to the utilization handler. It was pretty good as the initial implementation of utilization handlers, there are several drawbacks though. The biggest drawback is that the sg_cpu->flags field doesn't always represent

[PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

Currently the schedutil governor overwrites the sg_cpu->flags field on every call to the utilization handler. It was pretty good as the initial implementation of utilization handlers, there are several drawbacks though. The biggest drawback is that the sg_cpu->flags field doesn't always represent