Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On 13/07/17 15:42, Peter Zijlstra wrote: > On Thu, Jul 13, 2017 at 03:04:09PM +0100, Sudeep Holla wrote: > >> The question is whether we *need* to know the completion of frequency >> transition. What is the impact of absence of it ? I am considering >> platforms which may take up to a ms or

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On 13/07/17 15:42, Peter Zijlstra wrote: > On Thu, Jul 13, 2017 at 03:04:09PM +0100, Sudeep Holla wrote: > >> The question is whether we *need* to know the completion of frequency >> transition. What is the impact of absence of it ? I am considering >> platforms which may take up to a ms or

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On Thu, Jul 13, 2017 at 03:04:09PM +0100, Sudeep Holla wrote: > The question is whether we *need* to know the completion of frequency > transition. What is the impact of absence of it ? I am considering > platforms which may take up to a ms or more to do the actual transition > in the firmware.

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On Thu, Jul 13, 2017 at 03:04:09PM +0100, Sudeep Holla wrote: > The question is whether we *need* to know the completion of frequency > transition. What is the impact of absence of it ? I am considering > platforms which may take up to a ms or more to do the actual transition > in the firmware.

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On 13/07/17 14:08, Dietmar Eggemann wrote: > On 13/07/17 13:40, Sudeep Holla wrote: >> >> >> On 11/07/17 16:21, Dietmar Eggemann wrote: >>> On 11/07/17 07:39, Viresh Kumar wrote: On 10-07-17, 14:46, Rafael J. Wysocki wrote: > > [...] > >>> Like I said in the other email, since for

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On 13/07/17 14:08, Dietmar Eggemann wrote: > On 13/07/17 13:40, Sudeep Holla wrote: >> >> >> On 11/07/17 16:21, Dietmar Eggemann wrote: >>> On 11/07/17 07:39, Viresh Kumar wrote: On 10-07-17, 14:46, Rafael J. Wysocki wrote: > > [...] > >>> Like I said in the other email, since for

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On 12/07/17 12:14, Peter Zijlstra wrote: > On Wed, Jul 12, 2017 at 02:57:55PM +0530, Viresh Kumar wrote: >> On 12-07-17, 10:31, Peter Zijlstra wrote: >>> So the problem with the thread is two-fold; one the one hand we like the >>> scheduler to directly set frequency, but then we need to schedule

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On 12/07/17 12:14, Peter Zijlstra wrote: > On Wed, Jul 12, 2017 at 02:57:55PM +0530, Viresh Kumar wrote: >> On 12-07-17, 10:31, Peter Zijlstra wrote: >>> So the problem with the thread is two-fold; one the one hand we like the >>> scheduler to directly set frequency, but then we need to schedule

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On 13/07/17 13:40, Sudeep Holla wrote: > > > On 11/07/17 16:21, Dietmar Eggemann wrote: >> On 11/07/17 07:39, Viresh Kumar wrote: >>> On 10-07-17, 14:46, Rafael J. Wysocki wrote: [...] >> Like I said in the other email, since for (future) >> arm/arm64 fast-switch driver, the return value of >>

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On 13/07/17 13:40, Sudeep Holla wrote: > > > On 11/07/17 16:21, Dietmar Eggemann wrote: >> On 11/07/17 07:39, Viresh Kumar wrote: >>> On 10-07-17, 14:46, Rafael J. Wysocki wrote: [...] >> Like I said in the other email, since for (future) >> arm/arm64 fast-switch driver, the return value of >>

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On 12/07/17 10:27, Viresh Kumar wrote: > On 12-07-17, 10:31, Peter Zijlstra wrote: >> So the problem with the thread is two-fold; one the one hand we like the >> scheduler to directly set frequency, but then we need to schedule a task >> to change the frequency, which will change the frequency

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On 12/07/17 10:27, Viresh Kumar wrote: > On 12-07-17, 10:31, Peter Zijlstra wrote: >> So the problem with the thread is two-fold; one the one hand we like the >> scheduler to directly set frequency, but then we need to schedule a task >> to change the frequency, which will change the frequency

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On 12/07/17 05:09, Viresh Kumar wrote: > On 11-07-17, 16:06, Dietmar Eggemann wrote: >> But in the meantime we're convinced that cpufreq_driver_fast_switch() is >> not the right place to call arch_set_freq_scale() since for (future) >> arm/arm64 fast-switch driver, the return value of >>

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On 12/07/17 05:09, Viresh Kumar wrote: > On 11-07-17, 16:06, Dietmar Eggemann wrote: >> But in the meantime we're convinced that cpufreq_driver_fast_switch() is >> not the right place to call arch_set_freq_scale() since for (future) >> arm/arm64 fast-switch driver, the return value of >>

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On 11/07/17 16:21, Dietmar Eggemann wrote: > On 11/07/17 07:39, Viresh Kumar wrote: >> On 10-07-17, 14:46, Rafael J. Wysocki wrote: >>> This particular change is about a new feature, so making it in the core is >>> OK >>> in two cases IMO: (a) when you actively want everyone to be affected by

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On 11/07/17 16:21, Dietmar Eggemann wrote: > On 11/07/17 07:39, Viresh Kumar wrote: >> On 10-07-17, 14:46, Rafael J. Wysocki wrote: >>> This particular change is about a new feature, so making it in the core is >>> OK >>> in two cases IMO: (a) when you actively want everyone to be affected by

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On Thu, Jul 13, 2017 at 02:18:04PM +0530, Viresh Kumar wrote: > Workqueues or normal threads actually. Maybe I am completely wrong, > but this is how I believe things are going to be: > > Configuration: Both regulator and clk registers accessible over I2C > bus. > > Scheduler calls schedutil,

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On Thu, Jul 13, 2017 at 02:18:04PM +0530, Viresh Kumar wrote: > Workqueues or normal threads actually. Maybe I am completely wrong, > but this is how I believe things are going to be: > > Configuration: Both regulator and clk registers accessible over I2C > bus. > > Scheduler calls schedutil,

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On 13-07-17, 01:13, Rafael J. Wysocki wrote: > On Wednesday, July 12, 2017 01:14:26 PM Peter Zijlstra wrote: > > On Wed, Jul 12, 2017 at 02:57:55PM +0530, Viresh Kumar wrote: > > > IIUC, it will take more time to change the frequency eventually with > > > the interrupt-driven state machine as

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On 13-07-17, 01:13, Rafael J. Wysocki wrote: > On Wednesday, July 12, 2017 01:14:26 PM Peter Zijlstra wrote: > > On Wed, Jul 12, 2017 at 02:57:55PM +0530, Viresh Kumar wrote: > > > IIUC, it will take more time to change the frequency eventually with > > > the interrupt-driven state machine as

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On Thu, Jul 13, 2017 at 01:13:43AM +0200, Rafael J. Wysocki wrote: > I *guess* the concern is that in the new model there is no control over the > time of requesting the frequency change and when the change actually > happens. There isn't in any case. If some brilliant hardware designer shares

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On Thu, Jul 13, 2017 at 01:13:43AM +0200, Rafael J. Wysocki wrote: > I *guess* the concern is that in the new model there is no control over the > time of requesting the frequency change and when the change actually > happens. There isn't in any case. If some brilliant hardware designer shares

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On Wednesday, July 12, 2017 01:14:26 PM Peter Zijlstra wrote: > On Wed, Jul 12, 2017 at 02:57:55PM +0530, Viresh Kumar wrote: > > On 12-07-17, 10:31, Peter Zijlstra wrote: > > > So the problem with the thread is two-fold; one the one hand we like the > > > scheduler to directly set frequency, but

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On Wednesday, July 12, 2017 01:14:26 PM Peter Zijlstra wrote: > On Wed, Jul 12, 2017 at 02:57:55PM +0530, Viresh Kumar wrote: > > On 12-07-17, 10:31, Peter Zijlstra wrote: > > > So the problem with the thread is two-fold; one the one hand we like the > > > scheduler to directly set frequency, but

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On Wed, Jul 12, 2017 at 02:57:55PM +0530, Viresh Kumar wrote: > On 12-07-17, 10:31, Peter Zijlstra wrote: > > So the problem with the thread is two-fold; one the one hand we like the > > scheduler to directly set frequency, but then we need to schedule a task > > to change the frequency, which

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On Wed, Jul 12, 2017 at 02:57:55PM +0530, Viresh Kumar wrote: > On 12-07-17, 10:31, Peter Zijlstra wrote: > > So the problem with the thread is two-fold; one the one hand we like the > > scheduler to directly set frequency, but then we need to schedule a task > > to change the frequency, which

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On 12-07-17, 10:31, Peter Zijlstra wrote: > So the problem with the thread is two-fold; one the one hand we like the > scheduler to directly set frequency, but then we need to schedule a task > to change the frequency, which will change the frequency and around we > go. > > On the other hand,

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On 12-07-17, 10:31, Peter Zijlstra wrote: > So the problem with the thread is two-fold; one the one hand we like the > scheduler to directly set frequency, but then we need to schedule a task > to change the frequency, which will change the frequency and around we > go. > > On the other hand,

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On Wed, Jul 12, 2017 at 09:39:17AM +0530, Viresh Kumar wrote: > Yeah, I saw your discussion with Peter on #linux-rt IRC and TBH I wasn't aware > that we are going to do fast switching that way. Just trying to get > understanding of that idea a bit.. > > So we will do fast switching from

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On Wed, Jul 12, 2017 at 09:39:17AM +0530, Viresh Kumar wrote: > Yeah, I saw your discussion with Peter on #linux-rt IRC and TBH I wasn't aware > that we are going to do fast switching that way. Just trying to get > understanding of that idea a bit.. > > So we will do fast switching from

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On 11-07-17, 16:06, Dietmar Eggemann wrote: > But in the meantime we're convinced that cpufreq_driver_fast_switch() is > not the right place to call arch_set_freq_scale() since for (future) > arm/arm64 fast-switch driver, the return value of > cpufreq_driver->fast_switch() does not give us the

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On 11-07-17, 16:06, Dietmar Eggemann wrote: > But in the meantime we're convinced that cpufreq_driver_fast_switch() is > not the right place to call arch_set_freq_scale() since for (future) > arm/arm64 fast-switch driver, the return value of > cpufreq_driver->fast_switch() does not give us the

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On 11/07/17 07:39, Viresh Kumar wrote: > On 10-07-17, 14:46, Rafael J. Wysocki wrote: >> This particular change is about a new feature, so making it in the core is OK >> in two cases IMO: (a) when you actively want everyone to be affected by it >> and > > IMO this change should be done for the

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On 11/07/17 07:39, Viresh Kumar wrote: > On 10-07-17, 14:46, Rafael J. Wysocki wrote: >> This particular change is about a new feature, so making it in the core is OK >> in two cases IMO: (a) when you actively want everyone to be affected by it >> and > > IMO this change should be done for the

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On 11/07/17 15:59, Rafael J. Wysocki wrote: > On Tuesday, July 11, 2017 04:06:01 PM Dietmar Eggemann wrote: >> On 11/07/17 07:01, Viresh Kumar wrote: >>> On 10-07-17, 13:02, Dietmar Eggemann wrote: Yes, I will change this. The #define approach is not really necessary here since we're not

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On 11/07/17 15:59, Rafael J. Wysocki wrote: > On Tuesday, July 11, 2017 04:06:01 PM Dietmar Eggemann wrote: >> On 11/07/17 07:01, Viresh Kumar wrote: >>> On 10-07-17, 13:02, Dietmar Eggemann wrote: Yes, I will change this. The #define approach is not really necessary here since we're not

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On Tuesday, July 11, 2017 04:06:01 PM Dietmar Eggemann wrote: > On 11/07/17 07:01, Viresh Kumar wrote: > > On 10-07-17, 13:02, Dietmar Eggemann wrote: > >> Yes, I will change this. The #define approach is not really necessary > >> here since we're not in the scheduler hot-path and inlining is not

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On Tuesday, July 11, 2017 04:06:01 PM Dietmar Eggemann wrote: > On 11/07/17 07:01, Viresh Kumar wrote: > > On 10-07-17, 13:02, Dietmar Eggemann wrote: > >> Yes, I will change this. The #define approach is not really necessary > >> here since we're not in the scheduler hot-path and inlining is not

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On 11/07/17 07:01, Viresh Kumar wrote: > On 10-07-17, 13:02, Dietmar Eggemann wrote: >> Yes, I will change this. The #define approach is not really necessary >> here since we're not in the scheduler hot-path and inlining is not >> really required here. > > It would be part of scheduler hot-path

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On 11/07/17 07:01, Viresh Kumar wrote: > On 10-07-17, 13:02, Dietmar Eggemann wrote: >> Yes, I will change this. The #define approach is not really necessary >> here since we're not in the scheduler hot-path and inlining is not >> really required here. > > It would be part of scheduler hot-path

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On 10-07-17, 14:46, Rafael J. Wysocki wrote: > This particular change is about a new feature, so making it in the core is OK > in two cases IMO: (a) when you actively want everyone to be affected by it and IMO this change should be done for the whole ARM architecture. And if some regression

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On 10-07-17, 14:46, Rafael J. Wysocki wrote: > This particular change is about a new feature, so making it in the core is OK > in two cases IMO: (a) when you actively want everyone to be affected by it and IMO this change should be done for the whole ARM architecture. And if some regression

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On 10-07-17, 13:02, Dietmar Eggemann wrote: > Yes, I will change this. The #define approach is not really necessary > here since we're not in the scheduler hot-path and inlining is not > really required here. It would be part of scheduler hot-path for the fast-switching case, isn't it ? (I am not

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On 10-07-17, 13:02, Dietmar Eggemann wrote: > Yes, I will change this. The #define approach is not really necessary > here since we're not in the scheduler hot-path and inlining is not > really required here. It would be part of scheduler hot-path for the fast-switching case, isn't it ? (I am not

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On Monday, July 10, 2017 12:24:43 PM Viresh Kumar wrote: > On 08-07-17, 14:09, Rafael J. Wysocki wrote: > > I'm sort of wondering how many is "a lot" really. For instance, do you > > really > > want all of the existing ARM platforms to use the new stuff even though > > it may regress things

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On Monday, July 10, 2017 12:24:43 PM Viresh Kumar wrote: > On 08-07-17, 14:09, Rafael J. Wysocki wrote: > > I'm sort of wondering how many is "a lot" really. For instance, do you > > really > > want all of the existing ARM platforms to use the new stuff even though > > it may regress things

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On 08/07/17 13:09, Rafael J. Wysocki wrote: > On Friday, July 07, 2017 06:06:30 PM Dietmar Eggemann wrote: >> On 07/07/17 17:18, Rafael J. Wysocki wrote: >>> On Fri, Jul 7, 2017 at 6:01 PM, Dietmar Eggemann >>> wrote: On 06/07/17 11:40, Viresh Kumar wrote: > On

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On 08/07/17 13:09, Rafael J. Wysocki wrote: > On Friday, July 07, 2017 06:06:30 PM Dietmar Eggemann wrote: >> On 07/07/17 17:18, Rafael J. Wysocki wrote: >>> On Fri, Jul 7, 2017 at 6:01 PM, Dietmar Eggemann >>> wrote: On 06/07/17 11:40, Viresh Kumar wrote: > On 06-07-17, 10:49, Dietmar

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On 10/07/17 10:42, Viresh Kumar wrote: > On 10-07-17, 11:30, Peter Zijlstra wrote: >> On Sat, Jul 08, 2017 at 02:09:37PM +0200, Rafael J. Wysocki wrote: >>> Anyway, if everyone agrees that doing it in the core is the way to go >>> (Peter?), >>> why don't you introduce a __weak function for

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On 10/07/17 10:42, Viresh Kumar wrote: > On 10-07-17, 11:30, Peter Zijlstra wrote: >> On Sat, Jul 08, 2017 at 02:09:37PM +0200, Rafael J. Wysocki wrote: >>> Anyway, if everyone agrees that doing it in the core is the way to go >>> (Peter?), >>> why don't you introduce a __weak function for

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On 10-07-17, 11:30, Peter Zijlstra wrote: > On Sat, Jul 08, 2017 at 02:09:37PM +0200, Rafael J. Wysocki wrote: > > Anyway, if everyone agrees that doing it in the core is the way to go > > (Peter?), > > why don't you introduce a __weak function for setting policy->cur and > > override it from

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On 10-07-17, 11:30, Peter Zijlstra wrote: > On Sat, Jul 08, 2017 at 02:09:37PM +0200, Rafael J. Wysocki wrote: > > Anyway, if everyone agrees that doing it in the core is the way to go > > (Peter?), > > why don't you introduce a __weak function for setting policy->cur and > > override it from

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On Sat, Jul 08, 2017 at 02:09:37PM +0200, Rafael J. Wysocki wrote: > Anyway, if everyone agrees that doing it in the core is the way to go > (Peter?), > why don't you introduce a __weak function for setting policy->cur and > override it from your arch so as to call arch_set_freq_scale() from

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On Sat, Jul 08, 2017 at 02:09:37PM +0200, Rafael J. Wysocki wrote: > Anyway, if everyone agrees that doing it in the core is the way to go > (Peter?), > why don't you introduce a __weak function for setting policy->cur and > override it from your arch so as to call arch_set_freq_scale() from

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On 08-07-17, 14:09, Rafael J. Wysocki wrote: > I'm sort of wondering how many is "a lot" really. For instance, do you really > want all of the existing ARM platforms to use the new stuff even though > it may regress things there in principle? That's a valid question and we must (maybe we already

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On 08-07-17, 14:09, Rafael J. Wysocki wrote: > I'm sort of wondering how many is "a lot" really. For instance, do you really > want all of the existing ARM platforms to use the new stuff even though > it may regress things there in principle? That's a valid question and we must (maybe we already

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On 07-07-17, 17:01, Dietmar Eggemann wrote: > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c > index 9bf97a366029..77c4d5e7a598 100644 > --- a/drivers/cpufreq/cpufreq.c > +++ b/drivers/cpufreq/cpufreq.c > @@ -301,6 +301,12 @@ static void adjust_jiffies(unsigned long val, struct

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On 07-07-17, 17:01, Dietmar Eggemann wrote: > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c > index 9bf97a366029..77c4d5e7a598 100644 > --- a/drivers/cpufreq/cpufreq.c > +++ b/drivers/cpufreq/cpufreq.c > @@ -301,6 +301,12 @@ static void adjust_jiffies(unsigned long val, struct

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On Friday, July 07, 2017 06:06:30 PM Dietmar Eggemann wrote: > On 07/07/17 17:18, Rafael J. Wysocki wrote: > > On Fri, Jul 7, 2017 at 6:01 PM, Dietmar Eggemann > > wrote: > >> On 06/07/17 11:40, Viresh Kumar wrote: > >>> On 06-07-17, 10:49, Dietmar Eggemann wrote: > >

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On Friday, July 07, 2017 06:06:30 PM Dietmar Eggemann wrote: > On 07/07/17 17:18, Rafael J. Wysocki wrote: > > On Fri, Jul 7, 2017 at 6:01 PM, Dietmar Eggemann > > wrote: > >> On 06/07/17 11:40, Viresh Kumar wrote: > >>> On 06-07-17, 10:49, Dietmar Eggemann wrote: > > [...] > > >> So what about

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On 07/07/17 17:18, Rafael J. Wysocki wrote: > On Fri, Jul 7, 2017 at 6:01 PM, Dietmar Eggemann > wrote: >> On 06/07/17 11:40, Viresh Kumar wrote: >>> On 06-07-17, 10:49, Dietmar Eggemann wrote: [...] >> So what about I call arch_set_freq_scale() in

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On 07/07/17 17:18, Rafael J. Wysocki wrote: > On Fri, Jul 7, 2017 at 6:01 PM, Dietmar Eggemann > wrote: >> On 06/07/17 11:40, Viresh Kumar wrote: >>> On 06-07-17, 10:49, Dietmar Eggemann wrote: [...] >> So what about I call arch_set_freq_scale() in __cpufreq_notify_transition() >> in the >>

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On Fri, Jul 7, 2017 at 6:01 PM, Dietmar Eggemann wrote: > On 06/07/17 11:40, Viresh Kumar wrote: >> On 06-07-17, 10:49, Dietmar Eggemann wrote: > > [...] > >>> In case arch_set_freq_scale() is not defined (and because of the >>> pr_debug() drivers/cpufreq/cpufreq.c is

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On Fri, Jul 7, 2017 at 6:01 PM, Dietmar Eggemann wrote: > On 06/07/17 11:40, Viresh Kumar wrote: >> On 06-07-17, 10:49, Dietmar Eggemann wrote: > > [...] > >>> In case arch_set_freq_scale() is not defined (and because of the >>> pr_debug() drivers/cpufreq/cpufreq.c is not compiled with -DDEBUG)

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On 06/07/17 11:40, Viresh Kumar wrote: > On 06-07-17, 10:49, Dietmar Eggemann wrote: [...] >> In case arch_set_freq_scale() is not defined (and because of the >> pr_debug() drivers/cpufreq/cpufreq.c is not compiled with -DDEBUG) > > The line within () needs to be improved to convey a clear

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On 06/07/17 11:40, Viresh Kumar wrote: > On 06-07-17, 10:49, Dietmar Eggemann wrote: [...] >> In case arch_set_freq_scale() is not defined (and because of the >> pr_debug() drivers/cpufreq/cpufreq.c is not compiled with -DDEBUG) > > The line within () needs to be improved to convey a clear

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On Thursday, July 06, 2017 04:10:27 PM Viresh Kumar wrote: > On 06-07-17, 10:49, Dietmar Eggemann wrote: > > A frequency-invariant load-tracking solution based on cpufreq transition > > notifier will not work for future fast frequency switching policies. > > That is why a different solution is

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On Thursday, July 06, 2017 04:10:27 PM Viresh Kumar wrote: > On 06-07-17, 10:49, Dietmar Eggemann wrote: > > A frequency-invariant load-tracking solution based on cpufreq transition > > notifier will not work for future fast frequency switching policies. > > That is why a different solution is

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On 06-07-17, 10:49, Dietmar Eggemann wrote: > A frequency-invariant load-tracking solution based on cpufreq transition > notifier will not work for future fast frequency switching policies. > That is why a different solution is presented with this patch. > > Let cpufreq call the function

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On 06-07-17, 10:49, Dietmar Eggemann wrote: > A frequency-invariant load-tracking solution based on cpufreq transition > notifier will not work for future fast frequency switching policies. > That is why a different solution is presented with this patch. > > Let cpufreq call the function