Messages in this thread | | | Date | Thu, 26 Nov 2020 09:23:52 +0100 | From | Peter Zijlstra <> | Subject | Re: [PATCH -tip 09/32] sched/fair: Snapshot the min_vruntime of CPUs on force idle |
| |
On Thu, Nov 26, 2020 at 10:17:15AM +1100, Balbir Singh wrote: > On Tue, Nov 24, 2020 at 10:09:55AM +0100, Peter Zijlstra wrote:
> > The basic observation the current approach relies on is that al that > > faffery basically boils down to the fact that vruntime only means > > something when there is contention. And that only the progression is > > important not the actual value. That is, this is all fundamentally a > > differential equation and our integration constant is meaningless (also > > embodied in (7)). > > > > I'll reread (6) and (7), I am trying to understand forced idle and > contention together, from what I understand of the patches, there is
When we force-idle there is contention by definition; there's a task that wanted to run, but couldn't.
> 1. two tasks that are core scheduled, in that case vruntime works as > expected on each CPU, but we need to compare their combined vrtuntime > against other tasks on each CPU respectively for them to be > selected/chosen?
We need to compare across CPUs when the cookies don't match. This is required to avoid starving one or the other.
> 2. When one of the tasks selected is a part of the core scheduling group > and the other CPU does not select a core scheduled tasks, we need to ask > ourselves if that CPU should force idle and that's where this logic > comes into play?
When one CPU selects a cookie task, and the other CPU cannot find a matching task, it must go idle (as idle matches everyone). This is the basic core-scheduling constraint.
So suppose you have two tasks, A and B, both with a cookie, but not matching.
Normal scheduling would run A and B concurrent on the two siblings. Core scheduling obviously cannot do this. When we pick A, the other CPU is not allowed to run B and thus will have to be forced idle and vice-versa.
The next problem is avoiding starvation. Assuming equal weight between the tasks, we'd want to end up running A and B in alternating cycles.
This means having to compare runtimes between A and B, but when they're on different runqueues the actual vruntime values can be wildly divergent and cannot be reasily compared (the integration constant is meaningless but really annoying ;-).
We also cannot use min_vruntime (which is the same as the task vruntime when there is only a single task), because then you cannot observe progress. The difference between min_vruntime and the task runtime is always 0, so you can't tell who just ran and who got starved.
This is where our snapshots come in play, we snapshot vruntime after task selection (before running), such that at the next pick we can tell who made progress and who got starved.
By marking the vruntime of both runqueues at the same point in time we basically normalize away that integration constant. You effectively reset the vruntime to 0 (through (7), but without iterating all the tasks and adjusting it).
Does that make sense?
Once you get this, read that second email linked.
| |