12  * bfq_gt - compare two timestamps.
104 		 * entity, then compare timestamps to decide whether  in bfq_update_next_in_service()
802  * NOTE: this can be optimized, as the timestamps of upper level entities
890 	 * (virtual) finish timestamps may happen to become lower and  in bfq_update_fin_time_enqueue()
894 	 * higher timestamps happen to be busy, then the backshifted  in bfq_update_fin_time_enqueue()
895 	 * timestamps of the former queues can become much lower than  in bfq_update_fin_time_enqueue()
897 	 * higher timestamps while the ones with lower timestamps are  in bfq_update_fin_time_enqueue()
899 	 * higher values than the finish timestamps of the idle  in bfq_update_fin_time_enqueue()
900 	 * queues. As a consequence, the finish timestamps of all new  in bfq_update_fin_time_enqueue()
902 	 * those of lucky queues with backshifted timestamps. The  in bfq_update_fin_time_enqueue()
907 	 * backshifted timestamps of the queue associated with this  in bfq_update_fin_time_enqueue()
912 	 * with backshifted timestamps, but it does not break  in bfq_update_fin_time_enqueue()
916 	 * timestamps much less, to keep very low the probability that  in bfq_update_fin_time_enqueue()
917 	 * this push up causes the backshifted finish timestamps of  in bfq_update_fin_time_enqueue()
919 	 * finish timestamps of non weight-raised queues.  in bfq_update_fin_time_enqueue()
942  * Basically, this function updates the timestamps of entity and
1014  * present there, 2) updates the timestamps of entity and 3) inserts
1016  * the new values of the timestamps).
1034 		 *   reason; the timestamps of the entity need then to  in __bfq_requeue_entity()
1059 		 * the entity according to the new timestamps below.  in __bfq_requeue_entity()
1075 		 * timestamps below. This is the same approach as the  in __bfq_requeue_entity()
1370  * that would influence the timestamps of the entity (e.g., becomes idle,