Messages in this thread | | | Date | Tue, 7 Aug 2018 11:59:05 +0200 | From | Juri Lelli <> | Subject | Re: [PATCH v3 01/14] sched/core: uclamp: extend sched_setattr to support utilization clamping |
| |
Hi,
Minor comments below.
On 06/08/18 17:39, Patrick Bellasi wrote:
[...]
> + * > + * Task Utilization Attributes > + * =========================== > + * > + * A subset of sched_attr attributes allows to specify the utilization which > + * should be expected by a task. These attributes allows to inform the ^ allow
> + * scheduler about the utilization boundaries within which is safe to schedule
Isn't all this more about providing hints than safety?
> + * the task. These utilization boundaries are valuable information to support > + * scheduler decisions on both task placement and frequencies selection. > + * > + * @sched_util_min represents the minimum utilization > + * @sched_util_max represents the maximum utilization > + * > + * Utilization is a value in the range [0..SCHED_CAPACITY_SCALE] which > + * represents the percentage of CPU time used by a task when running at the > + * maximum frequency on the highest capacity CPU of the system. Thus, for > + * example, a 20% utilization task is a task running for 2ms every 10ms. > + * > + * A task with a min utilization value bigger then 0 is more likely to be > + * scheduled on a CPU which can provide that bandwidth. > + * A task with a max utilization value smaller then 1024 is more likely to be > + * scheduled on a CPU which do not provide more then the required bandwidth.
Isn't s/bandwidth/capacity/ here, above, and in general where you use the term "bandwidth" more appropriate? I wonder if overloading this term (w.r.t. how is used with DEADLINE) might create confusion. In this case we are not providing any sort of guarantees, it's a hint.
Best,
- Juri
| |