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.
905  * This holds even if low_latency is on, because weight-raised queues
921 	 *      non-weight-raised, and hence change its weight, and  in bfq_weights_tree_add()
1119 	 * mplayer took 23 seconds to start, if constantly weight-raised.  in bfq_wr_duration()
1730 			 *    raised at startup (as for any newly  in bfq_update_bfqq_wr_on_rq_arrival()
1744 			 *    weight-raised while they are pending.  in bfq_update_bfqq_wr_on_rq_arrival()
1851 	 * bfqq deserves to be weight-raised if:  in bfq_bfqq_handle_idle_busy_switch()
1953 	 * bfqq is at least as weight-raised, i.e., at least as time  in bfq_bfqq_handle_idle_busy_switch()
2343 	 * . if bfqq is not going to be weight-raised, because, for  in bfq_add_request()
2344 	 *   non weight-raised queues, last_wr_start_finish stores the  in bfq_add_request()
2349 	 * . if bfqq is not weight-raised, because, if bfqq is now  in bfq_add_request()
2350 	 *   switching to weight-raised, then last_wr_start_finish  in bfq_add_request()
2354 	 *   bfqq is currently weight-raised, the weight-raising  in bfq_add_request()
2357 	 *   conditions, if bfqq is already weight-raised)  in bfq_add_request()
2909  * WARNING: queue merging may impair fairness among non-weight raised
3086 		 * did not make it to be set in a weight-raised state,  in bfq_bfqq_save_state()
3182 	 * If bfqq is weight-raised, then let new_bfqq inherit  in bfq_merge_bfqqs()
3185 	 * to be weight-raised (which may happen because EQM may merge  in bfq_merge_bfqqs()
3395 	 * Unless the queue is being weight-raised or the scenario is  in bfq_arm_slice_timer()
3397 	 * is seeky. A long idling is preserved for a weight-raised  in bfq_arm_slice_timer()
3836  * non-weight-raised queues, for efficiency reasons (see comments on
3837  * bfq_weights_tree_add()). Then the fact that bfqq is weight-raised
3840  * weight-raised, the scenario is still symmetric if all queues with
3842  * weight-raised. Actually, we should be even more precise here, and
3872  * this problem for weight-raised queues.
3985 	      * Use a constant, low budget for weight-raised queues,  in __bfq_bfqq_recalc_budget()
4547 	 * weight-raised queues.  in idling_boosts_thr_without_issues()
4551 	 * non-weight-raised queues ask for requests at a lower rate,  in idling_boosts_thr_without_issues()
4552 	 * then processes associated with weight-raised queues have a  in idling_boosts_thr_without_issues()
4562 	 * there are weight-raised busy queues. In this case, and if  in idling_boosts_thr_without_issues()
4563 	 * bfqq is not weight-raised, this guarantees that the device  in idling_boosts_thr_without_issues()
4564 	 * is not idled for bfqq (if, instead, bfqq is weight-raised,  in idling_boosts_thr_without_issues()
4568 	 * sync non-weight-raised queue, to get a lower number of  in idling_boosts_thr_without_issues()
4571 	 * weight-raised queues get served again. This often mitigates  in idling_boosts_thr_without_issues()
4674 	 * - bfqq is not weight-raised and therefore does not carry  in bfq_choose_bfqq_for_injection()
4677 	 * - regardless of whether bfqq is weight-raised, bfqq has  in bfq_choose_bfqq_for_injection()
5052 	if (bfqq->wr_coeff > 1) { /* queue is being weight-raised */  in bfq_update_wr_data()
5102 	 * update weight both if it must be raised and if it must be  in bfq_update_wr_data()
5141 	 * weight-raised during this service slot, even if it has  in bfq_dispatch_rq_from_bfqq()
5143 	 * weight-raised queue. This inflates bfqq's timestamps, which  in bfq_dispatch_rq_from_bfqq()
5145 	 * device immediately to possible other weight-raised queues.  in bfq_dispatch_rq_from_bfqq()
6039 	 * inject limit to be raised again, and so on. The only effect  in bfq_update_has_short_ttime()
7135 	 * In-word depths if no bfq_queue is being weight-raised:  in bfq_update_depths()
7155 	 * raised: leaving ~63% of tags for sync reads. This is the  in bfq_update_depths()