kernel/sched/fair.c

565  * Fair schedulers conserve lag:
614  * maximal (virtual) lag induced in the system due to quantisation.
681  * and end up with a larger lag than we started with.
688  *   -r_max < lag < max(r_max, q)
711  * eg. lag >= 0.
3690 	 * adjusted if re-weight at !0-lag point.
3693 	 * re-weight without changing vruntime at !0-lag point.
3699 	 * Since lag needs to be preserved through re-weight:
3701 	 *	lag = (V - v)*w = (V'- v')*w', where v = v'
3716 	 * Since we are doing at !0-lag point which means V != v, we
3727 	 * at 0-lag point, thus breach assumption. Proof completed.
3749 	 * always occurs at 0-lag point, so V won't change. Or else
4498 	 * The lag estimation comes with a cost we don't want to pay all the
5180 	s64 lag = 0;
5187 	 * adding tasks with positive lag, or removing tasks with negative lag
5188 	 * will move 'time' backwards, this can screw around with the lag of
5197 		lag = se->vlag;
5200 		 * If we want to place a task and preserve lag, we have to
5202 		 * average and compensate for this, otherwise lag can quickly
5210 		 * the virtual lag:
5220 		 * Then, the weighted average after adding an entity with lag
5229 		 * And the actual lag after adding an entity with vl_i is:
5235 		 * Which is strictly less than vl_i. So in order to preserve lag
5236 		 * we should inflate the lag before placement such that the
5237 		 * effective lag after placement comes out right.
5240 		 * we need to use such that the lag after placement is the lag
5255 		lag *= load + scale_load_down(se->load.weight);
5258 		lag = div_s64(lag, load);
5261 	se->vruntime = vruntime - lag;
5315 	 * XXX now that the entity has been re-weighted, and it's lag adjusted,