lkml.org 
[lkml]   [2022]   [Sep]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH v4 6/8] sched/fair: Add sched group latency support
    On Wed, 21 Sept 2022 at 18:48, Tejun Heo <tj@kernel.org> wrote:
    >
    > Hello,
    >
    > On Wed, Sep 21, 2022 at 05:07:38PM +0100, Qais Yousef wrote:
    > > Wouldn't cpu.latency.nice be enough? I think the latency_offset is
    > > implementation detail that userspace shouldn't be concerned about.
    >
    > One option could be just using the same mapping as cpu.weight so that 100
    > maps to neutral, 10000 maps close to -20, 1 maps close to 19. It isn't great
    > that the value can't be interpreted in any intuitive way (e.g. a time
    > duration based interface would be a lot easier to grok even if it still is
    > best effort) but if that's what the per-task interface is gonna be, it'd be
    > best to keep cgroup interface in line.

    I would prefer a signed range like the [-1000:1000] as the behavior is
    different for sensitive and non sensitive task unlike the cpu.weight
    which is reflect that a bigger value get more

    >
    > As for whether a single value would fit the bill, it's again something which
    > should be answered for both task and cgroup based interface at the same
    > time. That said, my not-too-throught-through opinion is that a single value
    > for per-task / per-cgroup interface + system level knobs to fine tune how
    > that actually applies is likely enough and probably better than exposing
    > exposing a host of internal details to applications directly.
    >
    > Thanks.
    >
    > --
    > tejun

    \
     
     \ /
      Last update: 2022-09-21 19:04    [W:3.217 / U:1.804 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site