Messages in this thread | | | Date | Fri, 24 Feb 2023 20:29:19 +0100 | From | Michal Koutný <> | Subject | Re: [PATCH v12 6/8] sched/fair: Add sched group latency support |
| |
Hello Vincent.
On Fri, Feb 24, 2023 at 10:34:52AM +0100, Vincent Guittot <vincent.guittot@linaro.org> wrote: > + cpu.latency.nice > + A read-write single value file which exists on non-root > + cgroups. The default is "0". > + > + The nice value is in the range [-20, 19]. > + > + This interface file allows reading and setting latency using the > + same values used by sched_setattr(2). The latency_nice of a group is > + used to limit the impact of the latency_nice of a task outside the > + group.
IIUC, the latency priority is taken into account when deciding between entitites at the same level (as in pick_next_entity() or check_preempt_wake()/find_matchig_se()).
So this group attribute is relevant in context of siblings (i.e. like cpu.weight ~ bandwidth priority)?
I'm thus confused when it's referred to as a limit (in vertical sense). You somewhat imply that in [1]:
> Regarding the behavior, the rule remains the same that a sched_entity > attached to a cgroup will not get more (latency in this case) than > what has been set for the group entity.
But I don't see where such a constraint would be implemented in the code. (My cursory understanding above tends to horizontal comparisons.)
Could you please hint me which is right?
Thanks, Michal
[1] https://lore.kernel.org/r/CAKfTPtDu=c-psGnHkoWSPRWoh1Z0VBBfsN++g+krv4B1SJmFjg@mail.gmail.com/
[unhandled content-type:application/pgp-signature] | |