Messages in this thread | | | Date | Fri, 24 Mar 2023 11:03:52 +0100 | From | Peter Zijlstra <> | Subject | Re: [PATCH 06/10] sched/fair: Add avg_vruntime |
| |
On Fri, Mar 24, 2023 at 03:12:19PM +0800, Chen Yu wrote:
> > Or worse, SCHED_IDLE, where weight is 2 (IIRC) or cgroups, then vtime > > advances at 512 times realtime. Now, the tick puts a limit on how long > > we'll overshoot these super low weight entities, for HZ=1000 we still > > only get 0.5s of vtime for weight=2. > > > > That would be only 30 bits used, except we use double FIXEDPOINT_SHIFT > > on 64bit, so we'll end up at 40-ish. > > > > That should give us enough room to carry an average of deltas around > > min_vruntime. > > > I'm trying to digest how ticks could prevent the overflow.
They don't prevent overflow per se, but they do limit on how far vruntime can advance ahead of the pack.
> In update_curr() -> update_min_vruntime(cfs_rq), the cfs_rq->min_vruntime > is set to > max (cfs_rq->min_vruntime, min(curr->vruntime, leftmost(se->vruntime))) > so, although curr->vruntime increase by 0.5 seconds in each tick, > the leftmost(se->vruntime) could still be very small and unchanged, > thus the delta between v_i and cfs_rq->min_vruntime is still large.
Well, since the basic task selection rule is: pick leftmost, the idea is that leftmost and hence min_vruntime advances. The only problem is that placement can place new entities left of min_vruntime and then it stalls for a bit. But then rightmost tasks shouldn't get more runtime and the whole situation should be 'stable'-ish.
> Instead sysctl_sched_latency could decide how far it is between the > se.vruntime and the cfs_rq.min_vruntime, by calculating the vruntime > delta between task1 and task2: > > sched_vslice(task1) = (NICE0_LOAD/se1.weight) * (w1/Sum wi * sysctl_sched_latency) > sched_vslice(task2) = (NICE0_LOAD/se2.weight) * (w2/Sum wi * sysctl_sched_latency)
Yes, vslice is obviously involved, but low weight tasks are the ones that tend to shoot away and are tick limited.
> Besides in patch 10, entity_eligible() checks > \Sum (v_i - v)*w_i >= (v_i - v)*(\Sum w_i) > and the \Sum w_i could become large if there are many runnable tasks and > bring overflow?
Indeed; I'll check there too. I think I'll make it do the division on 32bit and use 64x64->128 on 64bit.
Let me have a play..
| |