Messages in this thread |  | | Date | Mon, 13 Aug 2018 14:27:14 +0200 | From | Juri Lelli <> | Subject | Re: [PATCH v3 01/14] sched/core: uclamp: extend sched_setattr to support utilization clamping |
| |
On 13/08/18 13:14, Patrick Bellasi wrote: > On 07-Aug 11:59, Juri Lelli wrote: > > 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? > > Yes, it's "just" hints... will rephrase to make it more clear. > > > > + * 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. > > Yes, you right... here we are not really granting any bandwidth but > just "improving" the bandwidth provisioning by hinting the scheduler > about a certain min/max capacity required. > > The problem related to using capacity is that, from kernel space, > capacity is defined as a static quantity/property of CPUs. Still, I
Looks like it's also more inline with EAS terminology (i.e., capacity states).
|  |