71  * weight-raised while it is deemed interactive, this maximum time
318  * weight-raised at the beginning of their I/O. On the opposite end,
319  * while being weight-raised, these applications
353  * have no right to be weight-raised any longer.
717  * This holds even if low_latency is on, because weight-raised queues
733 	 *      non-weight-raised, and hence change its weight, and  in bfq_weights_tree_add()
986 	 * mplayer took 23 seconds to start, if constantly weight-raised.  in bfq_wr_duration()
1580 			 *    raised at startup (as for any newly  in bfq_update_bfqq_wr_on_rq_arrival()
1594 			 *    weight-raised while they are pending.  in bfq_update_bfqq_wr_on_rq_arrival()
1670 	 * bfqq deserves to be weight-raised if:  in bfq_bfqq_handle_idle_busy_switch()
1767 	 * bfqq is at least as weight-raised, i.e., at least as time  in bfq_bfqq_handle_idle_busy_switch()
2088 	 * . if bfqq is not going to be weight-raised, because, for  in bfq_add_request()
2089 	 *   non weight-raised queues, last_wr_start_finish stores the  in bfq_add_request()
2094 	 * . if bfqq is not weight-raised, because, if bfqq is now  in bfq_add_request()
2095 	 *   switching to weight-raised, then last_wr_start_finish  in bfq_add_request()
2099 	 *   bfqq is currently weight-raised, the weight-raising  in bfq_add_request()
2102 	 *   conditions, if bfqq is already weight-raised)  in bfq_add_request()
2573  * WARNING: queue merging may impair fairness among non-weight raised
2701 		 * did not make it to be set in a weight-raised state,  in bfq_bfqq_save_state()
2754 	 * If bfqq is weight-raised, then let new_bfqq inherit  in bfq_merge_bfqqs()
2757 	 * to be weight-raised (which may happen because EQM may merge  in bfq_merge_bfqqs()
2967 	 * Unless the queue is being weight-raised or the scenario is  in bfq_arm_slice_timer()
2969 	 * is seeky. A long idling is preserved for a weight-raised  in bfq_arm_slice_timer()
3408  * non-weight-raised queues, for efficiency reasons (see comments on
3409  * bfq_weights_tree_add()). Then the fact that bfqq is weight-raised
3412  * weight-raised, the scenario is still symmetric if all queues with
3414  * weight-raised. Actually, we should be even more precise here, and
3444  * this problem for weight-raised queues.
3541 	      * Use a constant, low budget for weight-raised queues,  in __bfq_bfqq_recalc_budget()
4123 	 * weight-raised queues.  in idling_boosts_thr_without_issues()
4127 	 * non-weight-raised queues ask for requests at a lower rate,  in idling_boosts_thr_without_issues()
4128 	 * then processes associated with weight-raised queues have a  in idling_boosts_thr_without_issues()
4138 	 * there are weight-raised busy queues. In this case, and if  in idling_boosts_thr_without_issues()
4139 	 * bfqq is not weight-raised, this guarantees that the device  in idling_boosts_thr_without_issues()
4140 	 * is not idled for bfqq (if, instead, bfqq is weight-raised,  in idling_boosts_thr_without_issues()
4144 	 * sync non-weight-raised queue, to get a lower number of  in idling_boosts_thr_without_issues()
4147 	 * weight-raised queues get served again. This often mitigates  in idling_boosts_thr_without_issues()
4248 	 * - bfqq is not weight-raised and therefore does not carry  in bfq_choose_bfqq_for_injection()
4251 	 * - regardless of whether bfqq is weight-raised, bfqq has  in bfq_choose_bfqq_for_injection()
4540 	if (bfqq->wr_coeff > 1) { /* queue is being weight-raised */  in bfq_update_wr_data()
4578 	 * update weight both if it must be raised and if it must be  in bfq_update_wr_data()
4617 	 * weight-raised during this service slot, even if it has  in bfq_dispatch_rq_from_bfqq()
4619 	 * weight-raised queue. This inflates bfqq's timestamps, which  in bfq_dispatch_rq_from_bfqq()
4621 	 * device immediately to possible other weight-raised queues.  in bfq_dispatch_rq_from_bfqq()
5299 	 * inject limit to be raised again, and so on. The only effect  in bfq_update_has_short_ttime()
6325 	 * In-word depths if no bfq_queue is being weight-raised:  in bfq_update_depths()
6345 	 * raised: leaving ~63% of tags for sync reads. This is the  in bfq_update_depths()