lkml.org 
[lkml]   [2016]   [Mar]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH 0/3] cpufreq: Replace timers with utilization update callbacks
    On 1 March 2016 at 14:58, Peter Zijlstra <peterz@infradead.org> wrote:
    > On Fri, Feb 12, 2016 at 03:48:54PM +0100, Vincent Guittot wrote:
    >
    >> Another point to take into account is that the RT tasks will "steal"
    >> the compute capacity that has been requested by the cfs tasks.
    >>
    >> Let takes the example of a CPU with 3 OPP on which run 2 rt tasks A
    >> and B and 1 cfs task C.
    >
    >> Let assume that the real time constraint of RT task A is too agressive
    >> for the lowest OPP0 and that the change of the frequency of the core
    >> is too slow compare to this constraint but the real time constraint of
    >> RT task B can be handle whatever the OPP. System don't have other
    >> choice than setting the cpufreq min freq to OPP1 to be sure that
    >> constraint of task A will be covered at anytime.
    >
    >> Then, we still have 2
    >> possible OPPs. The CFS task asks for compute capacity that fits in
    >> OPP1 but a part of this capacity will be stolen by RT tasks. If we
    >> monitor the load of RT tasks and request capacity for these RT tasks
    >> according to their current utilization, we can decide to switch to
    >> highest OPP2 to ensure that task C will have enough remaining
    >> capacity. A lot of embedded platform faces such kind of use cases
    >
    > Still doesn't make sense. How would you know the constraint of RT task
    > A, and that it cannot be satisfied by OPP0 ? The only information you
    > have in the task model is a static priority.

    The kernel doesn't have this information so that's why the sysfs
    cpufreq/scaling_min_freq has to be used to prevent the kernel (and
    cpufreq in particular) to use OPP0.
    From a kernel/sched/cpufreq pov, we assume that all OPPs above
    cpufreq/scaling_min can be used with RT tasks of the system. And
    performance governor is used if only highest OPP can be used.

    >
    > The only possible choice the kernel has at this point is max OPP. It
    > doesn't have enough (_any_) information about worst case execution of
    > that task.
    >

    \
     
     \ /
      Last update: 2016-03-01 16:41    [W:2.410 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site