Messages in this thread | | | Date | Wed, 15 Apr 2020 12:07:41 +0800 | From | Aaron Lu <> | Subject | Re: [RFC PATCH 09/13] sched/fair: core wide vruntime comparison |
| |
On Wed, Apr 15, 2020 at 11:34:08AM +0800, Aaron Lu wrote: > On Tue, Apr 14, 2020 at 03:56:24PM +0200, Peter Zijlstra wrote: > > On Wed, Mar 04, 2020 at 04:59:59PM +0000, vpillai wrote: > > > From: Aaron Lu <aaron.lu@linux.alibaba.com> > > > > > > This patch provides a vruntime based way to compare two cfs task's > > > priority, be it on the same cpu or different threads of the same core. > > > > > > When the two tasks are on the same CPU, we just need to find a common > > > cfs_rq both sched_entities are on and then do the comparison. > > > > > > When the two tasks are on differen threads of the same core, the root > > > level sched_entities to which the two tasks belong will be used to do > > > the comparison. > > > > > > An ugly illustration for the cross CPU case: > > > > > > cpu0 cpu1 > > > / | \ / | \ > > > se1 se2 se3 se4 se5 se6 > > > / \ / \ > > > se21 se22 se61 se62 > > > > > > Assume CPU0 and CPU1 are smt siblings and task A's se is se21 while > > > task B's se is se61. To compare priority of task A and B, we compare > > > priority of se2 and se6. Whose vruntime is smaller, who wins. > > > > > > To make this work, the root level se should have a common cfs_rq min > > > vuntime, which I call it the core cfs_rq min vruntime. > > > > > > When we adjust the min_vruntime of rq->core, we need to propgate > > > that down the tree so as to not cause starvation of existing tasks > > > based on previous vruntime. > > > > You forgot the time complexity analysis. > > This is a mistake and the adjust should be needed only once when core > scheduling is initially enabled. It is an initialization thing and there > is no reason to do it in every invocation of coresched_adjust_vruntime().
Correction... I meant there is no need to call coresched_adjust_vruntime() in every invocation of update_core_cfs_rq_min_vruntime().
| |