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
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
317  * raising. These applications have basically no benefit from being
328  * finish explaining how the duration of weight-raising for
332  * raising is dynamically adjusted, as a function of the estimated
342  * duration of weight-raising for at least one class of I/O-bound
351  * overestimating the duration of weight raising. But, according to
355  * Basing on the last consideration, BFQ ends weight-raising for a
360  * This early ending of weight-raising reduces the amount of time
994 	 * preserve weight raising for too long.  in bfq_wr_duration()
998 	 * before weight-raising finishes.  in bfq_wr_duration()
1003 /* switch back from soft real-time to interactive weight raising */
1143  * possible, it is usually better to not grant either weight-raising
1155  * completed. As a consequence, weight-raising any of these queues,
1159  * weight-raising these new queues just lowers throughput in most
1190  * enjoy weight raising as expected. Fortunately these false positives
1525 		/* start a weight-raising period */  in bfq_update_bfqq_wr_on_rq_arrival()
1532 			 * No interactive weight raising in progress  in bfq_update_bfqq_wr_on_rq_arrival()
1536 			 * weight raising periods that is starting  in bfq_update_bfqq_wr_on_rq_arrival()
1537 			 * now, no interactive weight-raising period  in bfq_update_bfqq_wr_on_rq_arrival()
1573 			 * the weight-raising duration for the  in bfq_update_bfqq_wr_on_rq_arrival()
1574 			 * application with the weight-raising  in bfq_update_bfqq_wr_on_rq_arrival()
1578 			 * before the weight-raising period for the  in bfq_update_bfqq_wr_on_rq_arrival()
1585 			 *    at a certain time weight-raising is  in bfq_update_bfqq_wr_on_rq_arrival()
2098 	 *   stores the time when weight-raising starts  in bfq_add_request()
2101 	 *   bfqq is currently weight-raised, the weight-raising  in bfq_add_request()
2107 	 * real-time, because the weight-raising period is constantly  in bfq_add_request()
2711 	 * and weight raising state have already been saved. Do nothing.  in bfq_bfqq_save_state()
2727 		 * would have deserved interactive weight raising, but  in bfq_bfqq_save_state()
2730 		 * weight-raising state that would have been assigned  in bfq_bfqq_save_state()
2732 		 * to enjoy weight raising if split soon.  in bfq_bfqq_save_state()
2773 	/* Save weight raising and idle window of the merged queues */  in bfq_merge_bfqqs()
2782 	 * weight-raising. To reduce false positives, neglect the case  in bfq_merge_bfqqs()
2930 			 * of the weight-raising period forward by the  in __bfq_set_in_service_queue()
2934 			 * weight-raising period of the queue to end,  in __bfq_set_in_service_queue()
2936 			 * weight-raising period of a soft real-time  in __bfq_set_in_service_queue()
3443  * differentiate between interactive weight raising and soft real-time
3444  * weight raising.
3522 			 * the weight-raising mechanism.  in __bfq_bfqq_expire()
3985 		 * interactive weight raising. We do not do it in the  in bfq_bfqq_expire()
4570 			"raising period dur %u/%u msec, old coeff %u, w %d(%d)",  in bfq_update_wr_data()
4582 		 * weight-raising period, then end weight raising.  in bfq_update_wr_data()
4641 	 * If weight raising has to terminate for bfqq, then next  in bfq_dispatch_rq_from_bfqq()
5635 		 * no outstanding request; used by the weight-raising  in bfq_completed_request()
5683 	 * weight raising (see the comments in bfq_bfqq_expire() for  in bfq_completed_request()
6191 			 * possible weight raising period.  in bfq_init_rq()
6207 	 *    therefore in not weight-raising bfqq. See comments on  in bfq_init_rq()