On Wed, Jul 12, 2017 at 9:14 PM, Viresh Kumar wrote:
> On 12-07-17, 20:52, Joel Fernandes wrote:
>> Yes, that makes sense, its a bit subtle but I get what you're doing
>> now and I agree with it. Its also cleaner than my original patch :-)
>> and yeah definitely needs a comment ;-)
>
> And I have
On 12-07-17, 20:52, Joel Fernandes wrote:
> Yes, that makes sense, its a bit subtle but I get what you're doing
> now and I agree with it. Its also cleaner than my original patch :-)
> and yeah definitely needs a comment ;-)
And I have full trust on you to include that comment in you V5 :)
--
vi
On Wed, Jul 12, 2017 at 8:35 PM, Viresh Kumar wrote:
[..]
>
>> > diff --git a/kernel/sched/cpufreq_schedutil.c
>> > b/kernel/sched/cpufreq_schedutil.c
>> > index 076a2e31951c..3459f327c94e 100644
>> > --- a/kernel/sched/cpufreq_schedutil.c
>> > +++ b/kernel/sched/cpufreq_schedutil.c
>> > @@ -53,6
On 12-07-17, 15:28, Peter Zijlstra wrote:
> Hmm, so you're worried about that ratelimit stuff?
Yeah, somewhat.
> Shouldn't we fix that
> independently -- IIRC Rafael proposed a max-filter over the window.
I had some doubts about that idea in general and shared them earlier
with you:
https://mar
On 12-07-17, 19:02, Joel Fernandes wrote:
> On Tue, Jul 11, 2017 at 10:00 PM, Viresh Kumar
> wrote:
> Hmm, Ok. I can try to do some measurements about consecutive calls
> soon and let you know how often it happens. I also noticed its
> possible to call twice in the enqueue path itself as well.
Hi Viresh,
On Tue, Jul 11, 2017 at 10:00 PM, Viresh Kumar wrote:
[..]
>> Another approach than setting min in sugov_set_iowait_boost, is, since
>> we have already retrieved the current util, we can check if flags ==
>> SCHED_CPUFREQ_IOWAIT, then set initial the iowait_boost such that
>> (iowait_b
On Wed, Jul 12, 2017 at 03:16:23PM +0530, Viresh Kumar wrote:
> No, I wasn't clear enough. Sorry about that. Lemme try again:
>
> Suppose min freq is 500 MHz and Max is 2 GHz. The iowait-boost is
> set to 1 GHz right now (because of previous events with IOWAIT flag
> set), and sugov_set_iowait_bo
On 12-07-17, 11:36, Peter Zijlstra wrote:
> On Wed, Jul 12, 2017 at 10:30:35AM +0530, Viresh Kumar wrote:
> > On 11-07-17, 07:14, Joel Fernandes wrote:
>
> > > Another approach than setting min in sugov_set_iowait_boost, is, since
> > > we have already retrieved the current util, we can check if f
On Wed, Jul 12, 2017 at 10:30:35AM +0530, Viresh Kumar wrote:
> On 11-07-17, 07:14, Joel Fernandes wrote:
> > Another approach than setting min in sugov_set_iowait_boost, is, since
> > we have already retrieved the current util, we can check if flags ==
> > SCHED_CPUFREQ_IOWAIT, then set initial t
On 11-07-17, 07:14, Joel Fernandes wrote:
> I think the whole point of IOWAIT boost was to solve the issue with a
> long sequence of repeated I/O requests as described in the commit
> message. So IIUC there isn't a usecase for that (increase freq. on
> first request).
Right. So we can take example
On 11/07/17 07:33, Joel Fernandes wrote:
> Hi Juri,
>
> On Tue, Jul 11, 2017 at 12:14 AM, Juri Lelli wrote:
> [..]
> >> > Considering it a per-cpu thing, isn't enough that it gets bumped up or
> >> > decayed only when a CPU does an update (by using the above from
> >> > sugov_update_shared)?
> >>
Hi Juri,
On Tue, Jul 11, 2017 at 12:14 AM, Juri Lelli wrote:
[..]
>> > Considering it a per-cpu thing, isn't enough that it gets bumped up or
>> > decayed only when a CPU does an update (by using the above from
>> > sugov_update_shared)?
>> >
>> > If we go this way I think we will only need to re
On Tue, Jul 11, 2017 at 7:14 AM, Joel Fernandes wrote:
[..]
>>> + }
>>> } else if (sg_cpu->iowait_boost) {
>>> s64 delta_ns = time - sg_cpu->last_update;
>>>
>>> /* Clear iowait_boost if the CPU apprears to have been idle.
>>> */
>>> if
Hi Viresh,
On Tue, Jul 11, 2017 at 3:14 AM, Viresh Kumar wrote:
> On 09-07-17, 10:08, Joel Fernandes wrote:
>> diff --git a/kernel/sched/cpufreq_schedutil.c
>> b/kernel/sched/cpufreq_schedutil.c
>> index 622eed1b7658..4d9e8b96bed1 100644
>> --- a/kernel/sched/cpufreq_schedutil.c
>> +++ b/kernel/
On Sun, Jul 09, 2017 at 10:08:26AM -0700, Joel Fernandes wrote:
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -53,7 +53,9 @@ struct sugov_cpu {
> struct update_util_data update_util;
> struct sugov_policy *sg_policy;
>
> + bool prev_iowait_
On Tue, Jul 11, 2017 at 03:44:32PM +0530, Viresh Kumar wrote:
> On 09-07-17, 10:08, Joel Fernandes wrote:
> > diff --git a/kernel/sched/cpufreq_schedutil.c
> > b/kernel/sched/cpufreq_schedutil.c
> > index 622eed1b7658..4d9e8b96bed1 100644
> > --- a/kernel/sched/cpufreq_schedutil.c
> > +++ b/kernel
On 09-07-17, 10:08, Joel Fernandes wrote:
> diff --git a/kernel/sched/cpufreq_schedutil.c
> b/kernel/sched/cpufreq_schedutil.c
> index 622eed1b7658..4d9e8b96bed1 100644
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -53,7 +53,9 @@ struct sugov_cpu {
>
On 10/07/17 22:12, Joel Fernandes wrote:
> Hi Juri,
>
> On Mon, Jul 10, 2017 at 3:55 AM, Juri Lelli wrote:
> > Hi Joel,
> >
> > On 09/07/17 10:08, Joel Fernandes wrote:
[...]
> >> static void sugov_iowait_boost(struct sugov_cpu *sg_cpu, unsigned long
> >> *util,
> >> -
Hi Juri,
On Mon, Jul 10, 2017 at 3:55 AM, Juri Lelli wrote:
> Hi Joel,
>
> On 09/07/17 10:08, Joel Fernandes wrote:
>> Currently the iowait_boost feature in schedutil makes the frequency go to
>> max.
>> This feature was added to handle a case that Peter described where the
>> throughput of oper
Hi Joel,
On 09/07/17 10:08, Joel Fernandes wrote:
> Currently the iowait_boost feature in schedutil makes the frequency go to max.
> This feature was added to handle a case that Peter described where the
> throughput of operations involving continuous I/O requests [1] is reduced due
> to running a
Currently the iowait_boost feature in schedutil makes the frequency go to max.
This feature was added to handle a case that Peter described where the
throughput of operations involving continuous I/O requests [1] is reduced due
to running at a lower frequency, however the lower throughput itself ca
21 matches
Mail list logo
