Messages in this thread | | | Date | Tue, 6 Aug 2019 19:12:41 +0200 | From | Peter Zijlstra <> | Subject | Re: [RFC PATCH v3 00/16] Core scheduling v3 |
| |
On Tue, Aug 06, 2019 at 10:03:29AM -0700, Tim Chen wrote: > On 8/5/19 8:24 PM, Aaron Lu wrote: > > > I've been thinking if we should consider core wide tenent fairness? > > > > Let's say there are 3 tasks on 2 threads' rq of the same core, 2 tasks > > (e.g. A1, A2) belong to tenent A and the 3rd B1 belong to another tenent > > B. Assume A1 and B1 are queued on the same thread and A2 on the other > > thread, when we decide priority for A1 and B1, shall we also consider > > A2's vruntime? i.e. shall we consider A1 and A2 as a whole since they > > belong to the same tenent? I tend to think we should make fairness per > > core per tenent, instead of per thread(cpu) per task(sched entity). What > > do you guys think? > > > > Implemention of the idea is a mess to me, as I feel I'm duplicating the > > existing per cpu per sched_entity enqueue/update vruntime/dequeue logic > > for the per core per tenent stuff. > > I'm wondering if something simpler will work. It is easier to maintain fairness > between the CPU threads. A simple scheme may be if the force idle deficit > on a CPU thread exceeds a threshold compared to its sibling, we will > bias in choosing the task on the suppressed CPU thread. > The fairness among the tenents per run queue is balanced out by cfq fairness, > so things should be fair if we maintain fairness in CPU utilization between > the two CPU threads.
IIRC pjt once did a simle 5ms flip flop between siblings.
| |