Lines Matching refs: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
653 limit = DIV_ROUND_CLOSEST(limit * entity->weight, wsum);
683 * appropriate for their weight, we trim the available tag depth to 1. This
835 * 1) all active queues have the same weight,
838 * weight,
847 * 1) all active queues have the same weight,
887 * If the weight-counter tree passed as input contains no counter for
888 * the weight of the input queue, then add that counter; otherwise just
891 * Note that weight-counter trees contain few nodes in mostly symmetric
892 * scenarios. For example, if all queues have the same weight, then the
893 * weight-counter tree for the queues may contain at most one node.
894 * This holds even if low_latency is on, because weight-raised queues
910 * non-weight-raised, and hence change its weight, and
927 if (entity->weight == __counter->weight) {
931 if (entity->weight < __counter->weight)
944 * exit. This will cause the weight of queue to not be
947 * bfqq's weight would have been the only weight making the
957 bfqq->weight_counter->weight = entity->weight;
968 * Decrement the weight counter associated with the queue, and, if the
1108 * mplayer took 23 seconds to start, if constantly weight-raised.
1114 * preserve weight raising for too long.
1118 * before weight-raising finishes.
1123 /* switch back from soft real-time to interactive weight raising */
1160 * Restore weight coefficient only if low_latency is on
1187 /* make sure weight will be updated, however we got here */
1280 * possible, it is usually better to not grant either weight-raising
1292 * completed. As a consequence, weight-raising any of these queues,
1296 * weight-raising these new queues just lowers throughput in most
1308 * weight-raise all the queues created during the burst. This is the
1318 * weight-raise queues whose creation occurs in a large burst. In
1327 * enjoy weight raising as expected. Fortunately these false positives
1662 /* start a weight-raising period */
1669 * No interactive weight raising in progress
1673 * weight raising periods that is starting
1674 * now, no interactive weight-raising period
1710 * the weight-raising duration for the
1711 * application with the weight-raising
1715 * before the weight-raising period for the
1718 * 1) the weight of a soft rt application is
1722 * at a certain time weight-raising is
1733 * weight-raised while they are pending.
1762 * weight than the in-service queue.
1773 bfqq_weight = bfqq->entity.weight;
1774 in_serv_weight = in_serv_bfqq->entity.weight;
1777 bfqq_weight = bfqq->entity.parent->weight;
1779 bfqq_weight = bfqq->entity.weight;
1781 in_serv_weight = in_serv_bfqq->entity.parent->weight;
1783 in_serv_weight = in_serv_bfqq->entity.weight;
1840 * bfqq deserves to be weight-raised if:
1845 * - has a default weight (otherwise we assume the user wanted
1846 * to control its weight explicitly)
1858 * Merged bfq_queues are kept out of weight-raising
1866 * processes. So let also stably-merged queued enjoy weight
1942 * bfqq is at least as weight-raised, i.e., at least as time
1946 * or has a higher weight than the in-service queue. If this
2332 * . if bfqq is not going to be weight-raised, because, for
2333 * non weight-raised queues, last_wr_start_finish stores the
2336 * weight-raise async queues
2338 * . if bfqq is not weight-raised, because, if bfqq is now
2339 * switching to weight-raised, then last_wr_start_finish
2340 * stores the time when weight-raising starts
2343 * bfqq is currently weight-raised, the weight-raising
2346 * conditions, if bfqq is already weight-raised)
2349 * real-time, because the weight-raising period is constantly
2604 * If bfqq has been enjoying interactive weight-raising, then
2627 * Trigger a weight change on the next invocation of
2898 * WARNING: queue merging may impair fairness among non-weight raised
2899 * queues, for at least two reasons: 1) the original weight of a
2901 * weight the same, a merged queue may be bloated with many more
2968 * merged queues has a higher weight than a normal queue, then
2969 * the shared queue may inherit such a high weight and, by
3045 * and weight raising state have already been saved. Do nothing.
3070 * would have deserved interactive weight raising, but
3071 * did not make it to be set in a weight-raised state,
3073 * weight-raising state that would have been assigned
3075 * to enjoy weight raising if split soon.
3134 /* Save weight raising and idle window of the merged queues */
3165 * If bfqq is weight-raised, then let new_bfqq inherit
3166 * weight-raising. To reduce false positives, neglect the case
3168 * to be weight-raised (which may happen because EQM may merge
3295 timeout_coeff = bfqq->entity.weight / bfqq->entity.orig_weight;
3317 * of the weight-raising period forward by the
3321 * weight-raising period of the queue to end,
3323 * weight-raising period of a soft real-time
3382 * Unless the queue is being weight-raised or the scenario is
3384 * is seeky. A long idling is preserved for a weight-raised
3388 * needed if the queue has a higher weight than some other
3452 u32 rate, weight, divisor;
3497 * of the filter as a function of the 'weight' of the new
3500 * As can be seen in next formulas, we define this weight as a
3504 * The weight runs from 0 to 8. The maximum value of the
3505 * weight, 8, yields the minimum value for the smoothing
3510 * So, the first step is to compute the weight as a function
3511 * of how sequential the workload is. Note that the weight
3517 weight = (9 * bfqd->sequential_samples) / bfqd->peak_rate_samples;
3520 * Second step: further refine the weight as a function of the
3523 weight = min_t(u32, 8,
3524 div_u64(weight * bfqd->delta_from_first,
3528 * Divisor ranging from 10, for minimum weight, to 2, for
3529 * maximum weight.
3531 divisor = 10 - weight;
3770 * have the same weight.
3774 * However, for queues with the same weight, a further
3784 * groups have the same weight, this form of preemption,
3797 * that there are two queues with the same weight, but that
3806 * implies that, although both queues have the same weight,
3812 * queues with the same weight) is that, by not idling,
3823 * non-weight-raised queues, for efficiency reasons (see comments on
3824 * bfq_weights_tree_add()). Then the fact that bfqq is weight-raised
3827 * weight-raised, the scenario is still symmetric if all queues with
3829 * weight-raised. Actually, we should be even more precise here, and
3830 * differentiate between interactive weight raising and soft real-time
3831 * weight raising.
3859 * this problem for weight-raised queues.
3867 * lower weight than bfqq becomes busy (or more queues), (3) the new
3925 * the weight-raising mechanism.
3972 * Use a constant, low budget for weight-raised queues,
4534 * weight-raised queues.
4538 * non-weight-raised queues ask for requests at a lower rate,
4539 * then processes associated with weight-raised queues have a
4544 * weight. This is especially true with NCQ-capable drives,
4549 * there are weight-raised busy queues. In this case, and if
4550 * bfqq is not weight-raised, this guarantees that the device
4551 * is not idled for bfqq (if, instead, bfqq is weight-raised,
4555 * sync non-weight-raised queue, to get a lower number of
4558 * weight-raised queues get served again. This often mitigates
4661 * - bfqq is not weight-raised and therefore does not carry
4664 * - regardless of whether bfqq is weight-raised, bfqq has
5039 if (bfqq->wr_coeff > 1) { /* queue is being weight-raised */
5045 bfqq->entity.weight, bfqq->entity.orig_weight);
5053 * weight-raising period, then end weight raising.
5063 * Either in interactive weight
5064 * raising, or in soft_rt weight
5066 * interactive-weight-raising period
5068 * interactive weight raising).
5074 * interactive weight raising
5089 * update weight both if it must be raised and if it must be
5095 if ((entity->weight > entity->orig_weight) != (bfqq->wr_coeff > 1))
5124 * If weight raising has to terminate for bfqq, then next
5125 * function causes an immediate update of bfqq's weight,
5128 * weight-raised during this service slot, even if it has
5130 * weight-raised queue. This inflates bfqq's timestamps, which
5132 * device immediately to possible other weight-raised queues.
5928 * In soft_rt weight raising with the
5929 * interactive-weight-raising period
5931 * interactive weight raising).
5935 * stopping soft_rt weight raising
5937 * switch back to interactive weight
6364 * no outstanding request; used by the weight-raising
6425 * weight raising (see the comments in bfq_bfqq_expire() for
6941 * possible weight raising period.
6957 * therefore in not weight-raising bfqq. See comments on
7092 * In-word depths if no bfq_queue is being weight-raised:
7111 * In-word depths in case some bfq_queue is being weight-
7232 * Trigger weight initialization, according to ioprio, at the