Messages in this thread | | | Subject | Re: Scheduler wakeup path tuning surface: Interface discussion | From | Parth Shah <> | Date | Thu, 12 Nov 2020 11:43:46 +0530 |
| |
I was analyzing LPC 2020 discussion regarding Latency-nice interface and have below points to initiate further discussion:
1. There was consensus that having interface like "Latency-nice" to provide scheduler hints about task latency requirement can be very useful.
2. There are two use-case regarding the change in the number of CPUs to be searched in select_idle_cpu path: - milli-seconds optimization: Perform more scans to find idle CPUs to reduce latency in milliseconds - micro-seconds optimization: Perform less searches and queue it to any CPU when system is overloaded
Both these optimization are contradictory since one requires to reduce search space for latency sensitive task while other wants to increase it. Though we can think about tuning select_idle_cpu path by keeping mask of idle CPUs or applying other tricks, it will always be a trade-off to search more or less and that's where latency-nice like attribute can be useful for task aware decisions.
3. Using range is non-deterministic, meaning it is difficult to classify a task should be marked with value of -18 or -19 and there will be non-deterministic impact on system performance between these values.
And that's where should we even think of using "Flags" or other type instead of range where we just say if a task is latency-sensitive or not and won't classify if a task is "relatively" latency-nice than others?
Best, Parth
| |