Messages in this thread |  | | Date | Mon, 13 Aug 2018 13:14:41 +0100 | From | Patrick Bellasi <> | Subject | Re: [PATCH v3 01/14] sched/core: uclamp: extend sched_setattr to support utilization clamping |
| |
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 think it makes sense to argue that util_{min,max} are hints on the min/max capacity required for a task.
I'll update comments and text to avoid using bandwidth in favour of capacity.
Cheers Patrick
-- #include <best/regards.h>
Patrick Bellasi
|  |