lkml.org 
[lkml]   [2018]   [Aug]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v5 10/14] sched/cpufreq: Refactor the utilization aggregation method
    On Mon, Jul 30, 2018 at 12:35:27PM -0700, skannan@codeaurora.org wrote:
    > On 2018-07-24 05:25, Quentin Perret wrote:
    > If it's going to be a different aggregation from what's done for frequency
    > guidance, I don't see the point of having this inside schedutil. Why not
    > keep it inside the scheduler files? Also, it seems weird to use a governor's
    > code when it might not actually be in use. What if someone is using
    > ondemand, conservative, performance, etc?

    EAS hard relies on schedutil -- I suppose we need a check for that
    somewhere and maybe some infrastructure to pin the cpufreq governor.

    We're simply not going to support it for anything else.

    > > +enum schedutil_type {
    > > + frequency_util,
    > > + energy_util,
    > > +};
    >
    > Please don't use lower case for enums. It's extremely confusing.

    How is that confusing?

    \
     
     \ /
      Last update: 2018-08-02 14:34    [W:2.647 / U:0.024 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site