Messages in this thread | | | From | Vincent Guittot <> | Date | Wed, 21 Sep 2022 19:02:57 +0200 | Subject | Re: [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
| |