lkml.org 
[lkml]   [2020]   [May]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [RFC 0/3] Introduce cpufreq minimum load QoS
    Date


    On 4/30/20 5:50 PM, Valentin Schneider wrote:
    > On 30/04/20 16:37, Benjamin GAIGNARD wrote:
    >> On 4/30/20 4:33 PM, Valentin Schneider wrote:
    >>> On 30/04/20 14:46, Benjamin GAIGNARD wrote:
    >>>>> That's not what I meant.
    >>>>>
    >>>>> I suppose that the interrupt processing in question takes place in
    >>>>> process context and so you may set the lower clamp on the utilization
    >>>>> of the task carrying that out.
    >>>> I have try to add this code when starting streaming (before the first
    >>>> interrupt) the frames from the sensor:
    >>>> const struct sched_attr sched_attr = {
    >>>> .sched_util_min = 10000, /* 100% of usage */
    >>> Unless you play with SCHED_CAPACITY_SHIFT, the max should be 1024 -
    >>> i.e. SCHED_CAPACITY_SCALE. That's a really big boost, but that's for you to
    >>> benchmark.
    >>>
    >>>> .sched_flags = SCHED_FLAG_UTIL_CLAMP_MIN,
    >>>> };
    >>>>
    >>>> sched_setattr(current, &sched_attr);
    >>>>
    >>>> I don't see any benefices maybe there is some configuration flags to set.
    >>>>
    >>>> How changing sched_util_min could impact cpufreq ondemand governor ?
    >>>> Does it change the value returned when the governor check the idle time ?
    >>>>
    >>> You'll have to use the schedutil governor for uclamp to have an effect. And
    >>> arguably that's what you should be using, unless something explicitly
    >>> prevents you from doing that.
    >> Even with schedutil and SCHED_CAPACITY_SCALE that it doesn't work.
    >> cpufreq/cpuinfo_cur_freq values are always on the max value even if the
    >> stats show transitions between the available frequencies.
    >>
    >> I see two possibles reasons to explain that:
    >> - sched_setattr() is called in userland process context, but the
    >> threaded irq handler is running in another process.
    > Ah yes, this only works if the task you boost is the one that will handle
    > whatever work you care about (in this case handling the irq). That said, if
    > you do use threaded IRQs, that should give you a SCHED_FIFO thread, which
    > should drive the frequency to its max when using schedutil (unrelated to
    > uclamp).
    Can I conclude that sched_setattr() isn't the good way to solve this
    problem ?
    Does my patches make sense in this case ?

    >> - because this use case is almost running all in hardware the process
    >> isn't doing anything so the scheduler doesn't take care of it.
    >>
    >>>>> Alternatively, that task may be a deadline one.
    \
     
     \ /
      Last update: 2020-05-04 11:18    [W:3.332 / U:0.252 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site