Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1697739

Re: [Eas-dev] [PATCH V4 0/3] sched: cpufreq: Allow remote callbacks

From "Joel Fernandes (Google)" <joel.opensrc@gmail.com>
Newsgroups linux.kernel
Subject Re: [Eas-dev] [PATCH V4 0/3] sched: cpufreq: Allow remote callbacks
Date 2017-07-27 08:30 +0200
Message-ID <u7Kt4-2Ab-5@gated-at.bofh.it> (permalink)
References <u7qNI-6Vf-3@gated-at.bofh.it> <u7Jnk-1WL-15@gated-at.bofh.it> <u7JQl-28o-7@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


Hi Viresh,

On Wed, Jul 26, 2017 at 10:46 PM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 26-07-17, 22:14, Joel Fernandes (Google) wrote:
<snip>
>> Also one more comment about this usecase:
>>
>> You mentioned in our discussion at [2] sometime back, about the
>> question of initial utilization,
>>
>> "We don't have any such configurable way possible right
>> now, but there were discussions on how much utilization should a new
>> task be assigned when it first comes up."
>
> We still initialize it to a value, just that it isn't configurable.
> See below..
>
>> But, then in your cover letter above, you mentioned "This is verified
>> using ftrace". So my question is how has this been verified with
>> ftrace if the new initial utilization as you said in [2] is currently
>> still under discussion? Basically how could you verify with ftrace
>> that the target CPU frequency isn't increasing immediately on spawning
>> of a new task remotely, if the initial utilization of a new task isn't
>> something we set/configure with current code? Am I missing something?
>>
>> [2] https://lists.linaro.org/pipermail/eas-dev/2017-January/000785.html
>
> The statement "new tasks should receive maximum demand initially" is
> used to represent tasks which have high demand every time they run.
> For example scrolling of a web page or gallery on our phones. Yes,
> maybe I can use the work "migrated" (as you suggested later) as the
> history of its utilization will move with it then to the new CPU.
>
> But even without that, if you see the routine
> init_entity_runnable_average() in fair.c, the new tasks are
> initialized in a way that they are seen as heavy tasks. And so even
> for the first time they run, freq should normally increase on the
> target CPU (at least with above application).i

Ok, but the "heavy" in init_entity_runnable_average means for load,
not the util_avg. The util_avg is what's used for frequency scaling
IIUC and is set to 0 in that function no?

>
> The application was written by Steve (all credit goes to him) before
> he left Linaro, but I did test it with ftrace. What I saw with ftrace
> was that the freq isn't reevaluated for almost an entire tick many
> times because we enqueued the task remotely. And that changes with
> this series.
>
>> > The reason being that this patchset only targets a corner case, where
>> > following are required to be true to improve performance and that
>> > doesn't happen too often with these tests:
>> >
>> > - Task is migrated to another CPU.
>> > - The task has maximum demand initially, and should take the CPU to
>>
>> Just to make the cover-letter more clear and also confirming with you
>> I understand the above usecase, maybe in the future this can reworded
>> from "initially" to "before the migration" and "take the CPU" to "take
>> the target CPU of the migration" ?
>
> I can reword it a bit, but the test case wasn't really migrating
> anything and was looking only at the initial loads.

Ok, I wasn't talking about the synthetic test in the second part of my
email above but about the explanation you gave about Galleryfling
improvement (that the migration of a task with high utilization
doesn't update the target frequency) which makes sense to me so we are
on the same page about that.

thanks,

-Joel

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH V4 0/3] sched: cpufreq: Allow remote callbacks Viresh Kumar <viresh.kumar@linaro.org> - 2017-07-26 11:30 +0200
  [PATCH V4 2/3] cpufreq: schedutil: Process remote callback for shared policies Viresh Kumar <viresh.kumar@linaro.org> - 2017-07-26 11:30 +0200
    Re: [Eas-dev] [PATCH V4 2/3] cpufreq: schedutil: Process remote  callback for shared policies "Joel Fernandes (Google)" <joel.opensrc@gmail.com> - 2017-07-27 07:50 +0200
  [PATCH V4 1/3] sched: cpufreq: Allow remote cpufreq callbacks Viresh Kumar <viresh.kumar@linaro.org> - 2017-07-26 11:30 +0200
    Re: [PATCH V4 1/3] sched: cpufreq: Allow remote cpufreq callbacks "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2017-07-26 20:00 +0200
      Re: [PATCH V4 1/3] sched: cpufreq: Allow remote cpufreq callbacks Viresh Kumar <viresh.kumar@linaro.org> - 2017-07-27 05:30 +0200
    Re: [Eas-dev] [PATCH V4 1/3] sched: cpufreq: Allow remote cpufreq callbacks "Joel Fernandes (Google)" <joel.opensrc@gmail.com> - 2017-07-27 07:40 +0200
      Re: [Eas-dev] [PATCH V4 1/3] sched: cpufreq: Allow remote cpufreq  callbacks Viresh Kumar <viresh.kumar@linaro.org> - 2017-07-27 08:00 +0200
        Re: [Eas-dev] [PATCH V4 1/3] sched: cpufreq: Allow remote cpufreq callbacks "Joel Fernandes (Google)" <joel.opensrc@gmail.com> - 2017-07-27 08:20 +0200
          Re: [Eas-dev] [PATCH V4 1/3] sched: cpufreq: Allow remote cpufreq  callbacks Viresh Kumar <viresh.kumar@linaro.org> - 2017-07-27 09:20 +0200
            Re: [Eas-dev] [PATCH V4 1/3] sched: cpufreq: Allow remote cpufreq  callbacks Peter Zijlstra <peterz@infradead.org> - 2017-07-27 11:20 +0200
            Re: [Eas-dev] [PATCH V4 1/3] sched: cpufreq: Allow remote cpufreq callbacks "Joel Fernandes (Google)" <joel.opensrc@gmail.com> - 2017-07-28 05:40 +0200
    Re: [PATCH V4 1/3] sched: cpufreq: Allow remote cpufreq callbacks Peter Zijlstra <peterz@infradead.org> - 2017-07-27 12:00 +0200
  [PATCH V4 3/3] cpufreq: governor: Process remote callback for shared policies Viresh Kumar <viresh.kumar@linaro.org> - 2017-07-26 11:30 +0200
  Re: [Eas-dev] [PATCH V4 0/3] sched: cpufreq: Allow remote callbacks "Joel Fernandes (Google)" <joel.opensrc@gmail.com> - 2017-07-27 07:20 +0200
    Re: [Eas-dev] [PATCH V4 0/3] sched: cpufreq: Allow remote callbacks Viresh Kumar <viresh.kumar@linaro.org> - 2017-07-27 07:50 +0200
      Re: [Eas-dev] [PATCH V4 0/3] sched: cpufreq: Allow remote callbacks "Joel Fernandes (Google)" <joel.opensrc@gmail.com> - 2017-07-27 08:30 +0200
        Re: [Eas-dev] [PATCH V4 0/3] sched: cpufreq: Allow remote callbacks Viresh Kumar <viresh.kumar@linaro.org> - 2017-07-27 09:20 +0200
        Re: [Eas-dev] [PATCH V4 0/3] sched: cpufreq: Allow remote callbacks Juri Lelli <juri.lelli@arm.com> - 2017-07-27 09:30 +0200
          Re: [Eas-dev] [PATCH V4 0/3] sched: cpufreq: Allow remote callbacks "Joel Fernandes (Google)" <joel.opensrc@gmail.com> - 2017-07-28 05:50 +0200

csiph-web