Lines Matching defs:lag

601  * and this value should be no more than two lag bounds. Which puts it in the
612  * being the zero-lag point).
625  * Fair schedulers conserve lag:
673  * deltas: (v_i - v0), will be in the order of the maximal (virtual) lag
778  * the bound on entity_key() is at most two lag bounds.
823  * and end up with a larger lag than we started with.
830  *   -r_max < lag < max(r_max, q)
844  * Delayed dequeue aims to reduce the negative lag of a dequeued task. While
845  * updating the lag of an entity, check that negative lag didn't increase
847  * Similarly, check that the entity didn't gain positive lag when DELAY_ZERO
879  * eg. lag >= 0.
3946 	 * adjusted if re-weight at !0-lag point.
3949 	 * re-weight without changing vruntime at !0-lag point.
3955 	 * Since lag needs to be preserved through re-weight:
3957 	 *	lag = (V - v)*w = (V'- v')*w', where v = v'
3972 	 * Since we are doing at !0-lag point which means V != v, we
3983 	 * at 0-lag point, thus breach assumption. Proof completed.
4005 	 * always occurs at 0-lag point, so V won't change. Or else
4734 	 * The lag estimation comes with a cost we don't want to pay all the
5356 	s64 lag = 0;
5364 	 * adding tasks with positive lag, or removing tasks with negative lag
5365 	 * will move 'time' backwards, this can screw around with the lag of
5374 		lag = se->vlag;
5377 		 * If we want to place a task and preserve lag, we have to
5379 		 * average and compensate for this, otherwise lag can quickly
5387 		 * the virtual lag:
5397 		 * Then, the weighted average after adding an entity with lag
5406 		 * And the actual lag after adding an entity with vl_i is:
5412 		 * Which is strictly less than vl_i. So in order to preserve lag
5413 		 * we should inflate the lag before placement such that the
5414 		 * effective lag after placement comes out right.
5417 		 * we need to use such that the lag after placement is the lag
5433 		lag *= load + weight;
5436 		lag = div64_long(lag, load);
5462 	se->vruntime = vruntime - lag;
5465 		update_zero_vruntime(cfs_rq, -lag);
5526 	 * XXX now that the entity has been re-weighted, and it's lag adjusted,
13423  * From which we can define the lag, or deviation from the ideal, as:
13425  *   lag(i) = S - s_i                                         (4)
13429  *   \Sum_i w_i lag(i) := 0                                   (5)
13493  * On which we can define a combined lag:
13506  *     compare the combined lag, per (11).
13519  * then increases due to not being idle, and the idle one builds up lag to
13523  * we sync to 0 and let the idle one build up lag to get re-election. Now
13525  * again would destroy the built-up lag from the queue that was already
13535  * IOW, we can recast the (lag) comparison to a one-sided difference.
13542  * and for already idle queues to preserve their build-up lag.