Lines Matching defs:weight
33 * process/queue is assigned a user-configurable weight, and B-WF2Q+
35 * proportional to its weight. Thanks to the accurate policy of
54 * mainly, by raising the weight of the queue. So, for brevity, we
55 * call just weight-raising periods the time periods during which a
71 * weight-raised while it is deemed interactive, this maximum time
73 * weight-raising for interactive queues.
271 * When configured for computing the duration of the weight-raising
285 * weight raising to interactive applications.
313 * BFQ uses the above-detailed, time-based weight-raising mechanism to
316 * doing I/O for much longer than the duration of weight
318 * weight-raised at the beginning of their I/O. On the opposite end,
319 * while being weight-raised, these applications
328 * finish explaining how the duration of weight-raising for
331 * For a bfq_queue deemed as interactive, the duration of weight
342 * duration of weight-raising for at least one class of I/O-bound
351 * overestimating the duration of weight raising. But, according to
353 * have no right to be weight-raised any longer.
355 * Basing on the last consideration, BFQ ends weight-raising for a
360 * This early ending of weight-raising reduces the amount of time
666 * 1) all active queues have the same weight,
669 * weight,
678 * 1) all active queues have the same weight,
718 * If the weight-counter tree passed as input contains no counter for
719 * the weight of the input queue, then add that counter; otherwise just
722 * Note that weight-counter trees contain few nodes in mostly symmetric
723 * scenarios. For example, if all queues have the same weight, then the
724 * weight-counter tree for the queues may contain at most one node.
725 * This holds even if low_latency is on, because weight-raised queues
741 * non-weight-raised, and hence change its weight, and
758 if (entity->weight == __counter->weight) {
762 if (entity->weight < __counter->weight)
775 * exit. This will cause the weight of queue to not be
778 * bfqq's weight would have been the only weight making the
788 bfqq->weight_counter->weight = entity->weight;
799 * Decrement the weight counter associated with the queue, and, if the
994 * mplayer took 23 seconds to start, if constantly weight-raised.
1000 * preserve weight raising for too long.
1004 * before weight-raising finishes.
1009 /* switch back from soft real-time to interactive weight raising */
1057 /* make sure weight will be updated, however we got here */
1149 * possible, it is usually better to not grant either weight-raising
1161 * completed. As a consequence, weight-raising any of these queues,
1165 * weight-raising these new queues just lowers throughput in most
1177 * weight-raise all the queues created during the burst. This is the
1187 * weight-raise queues whose creation occurs in a large burst. In
1196 * enjoy weight raising as expected. Fortunately these false positives
1531 /* start a weight-raising period */
1538 * No interactive weight raising in progress
1542 * weight raising periods that is starting
1543 * now, no interactive weight-raising period
1579 * the weight-raising duration for the
1580 * application with the weight-raising
1584 * before the weight-raising period for the
1587 * 1) the weight of a soft rt application is
1591 * at a certain time weight-raising is
1602 * weight-raised while they are pending.
1631 * weight than the in-service queue.
1642 bfqq_weight = bfqq->entity.weight;
1643 in_serv_weight = in_serv_bfqq->entity.weight;
1646 bfqq_weight = bfqq->entity.parent->weight;
1648 bfqq_weight = bfqq->entity.weight;
1650 in_serv_weight = in_serv_bfqq->entity.parent->weight;
1652 in_serv_weight = in_serv_bfqq->entity.weight;
1678 * bfqq deserves to be weight-raised if:
1775 * bfqq is at least as weight-raised, i.e., at least as time
1779 * or has a higher weight than the in-service queue. If this
2096 * . if bfqq is not going to be weight-raised, because, for
2097 * non weight-raised queues, last_wr_start_finish stores the
2100 * weight-raise async queues
2102 * . if bfqq is not weight-raised, because, if bfqq is now
2103 * switching to weight-raised, then last_wr_start_finish
2104 * stores the time when weight-raising starts
2107 * bfqq is currently weight-raised, the weight-raising
2110 * conditions, if bfqq is already weight-raised)
2113 * real-time, because the weight-raising period is constantly
2384 * Trigger a weight change on the next invocation of
2613 * WARNING: queue merging may impair fairness among non-weight raised
2614 * queues, for at least two reasons: 1) the original weight of a
2616 * weight the same, a merged queue may be bloated with many more
2650 * merged queues has a higher weight than a normal queue, then
2651 * the shared queue may inherit such a high weight and, by
2725 * and weight raising state have already been saved. Do nothing.
2741 * would have deserved interactive weight raising, but
2742 * did not make it to be set in a weight-raised state,
2744 * weight-raising state that would have been assigned
2746 * to enjoy weight raising if split soon.
2787 /* Save weight raising and idle window of the merged queues */
2795 * If bfqq is weight-raised, then let new_bfqq inherit
2796 * weight-raising. To reduce false positives, neglect the case
2798 * to be weight-raised (which may happen because EQM may merge
2922 timeout_coeff = bfqq->entity.weight / bfqq->entity.orig_weight;
2944 * of the weight-raising period forward by the
2948 * weight-raising period of the queue to end,
2950 * weight-raising period of a soft real-time
3009 * Unless the queue is being weight-raised or the scenario is
3011 * is seeky. A long idling is preserved for a weight-raised
3015 * needed if the queue has a higher weight than some other
3079 u32 rate, weight, divisor;
3124 * of the filter as a function of the 'weight' of the new
3127 * As can be seen in next formulas, we define this weight as a
3131 * The weight runs from 0 to 8. The maximum value of the
3132 * weight, 8, yields the minimum value for the smoothing
3137 * So, the first step is to compute the weight as a function
3138 * of how sequential the workload is. Note that the weight
3144 weight = (9 * bfqd->sequential_samples) / bfqd->peak_rate_samples;
3147 * Second step: further refine the weight as a function of the
3150 weight = min_t(u32, 8,
3151 div_u64(weight * bfqd->delta_from_first,
3155 * Divisor ranging from 10, for minimum weight, to 2, for
3156 * maximum weight.
3158 divisor = 10 - weight;
3397 * have the same weight.
3401 * However, for queues with the same weight, a further
3411 * groups have the same weight, this form of preemption,
3424 * that there are two queues with the same weight, but that
3433 * implies that, although both queues have the same weight,
3439 * queues with the same weight) is that, by not idling,
3450 * non-weight-raised queues, for efficiency reasons (see comments on
3451 * bfq_weights_tree_add()). Then the fact that bfqq is weight-raised
3454 * weight-raised, the scenario is still symmetric if all queues with
3456 * weight-raised. Actually, we should be even more precise here, and
3457 * differentiate between interactive weight raising and soft real-time
3458 * weight raising.
3486 * this problem for weight-raised queues.
3536 * the weight-raising mechanism.
3583 * Use a constant, low budget for weight-raised queues,
3999 * interactive weight raising. We do not do it in the
4165 * weight-raised queues.
4169 * non-weight-raised queues ask for requests at a lower rate,
4170 * then processes associated with weight-raised queues have a
4175 * weight. This is especially true with NCQ-capable drives,
4180 * there are weight-raised busy queues. In this case, and if
4181 * bfqq is not weight-raised, this guarantees that the device
4182 * is not idled for bfqq (if, instead, bfqq is weight-raised,
4186 * sync non-weight-raised queue, to get a lower number of
4189 * weight-raised queues get served again. This often mitigates
4290 * - bfqq is not weight-raised and therefore does not carry
4293 * - regardless of whether bfqq is weight-raised, bfqq has
4582 if (bfqq->wr_coeff > 1) { /* queue is being weight-raised */
4588 bfqq->entity.weight, bfqq->entity.orig_weight);
4596 * weight-raising period, then end weight raising.
4620 * update weight both if it must be raised and if it must be
4626 if ((entity->weight > entity->orig_weight) != (bfqq->wr_coeff > 1))
4655 * If weight raising has to terminate for bfqq, then next
4656 * function causes an immediate update of bfqq's weight,
4659 * weight-raised during this service slot, even if it has
4661 * weight-raised queue. This inflates bfqq's timestamps, which
4663 * device immediately to possible other weight-raised queues.
5656 * no outstanding request; used by the weight-raising
5704 * weight raising (see the comments in bfq_bfqq_expire() for
6190 * possible weight raising period.
6206 * therefore in not weight-raising bfqq. See comments on
6339 * In-word depths if no bfq_queue is being weight-raised:
6358 * In-word depths in case some bfq_queue is being weight-
6475 * Trigger weight initialization, according to ioprio, at the