12  * bfq_gt - compare two timestamps.
104 		 * entity, then compare timestamps to decide whether  in bfq_update_next_in_service()
783  * NOTE: this can be optimized, as the timestamps of upper level entities
871 	 * (virtual) finish timestamps may happen to become lower and  in bfq_update_fin_time_enqueue()
875 	 * higher timestamps happen to be busy, then the backshifted  in bfq_update_fin_time_enqueue()
876 	 * timestamps of the former queues can become much lower than  in bfq_update_fin_time_enqueue()
878 	 * higher timestamps while the ones with lower timestamps are  in bfq_update_fin_time_enqueue()
880 	 * higher values than the finish timestamps of the idle  in bfq_update_fin_time_enqueue()
881 	 * queues. As a consequence, the finish timestamps of all new  in bfq_update_fin_time_enqueue()
883 	 * those of lucky queues with backshifted timestamps. The  in bfq_update_fin_time_enqueue()
888 	 * backshifted timestamps of the queue associated with this  in bfq_update_fin_time_enqueue()
893 	 * with backshifted timestamps, but it does not break  in bfq_update_fin_time_enqueue()
897 	 * timestamps much less, to keep very low the probability that  in bfq_update_fin_time_enqueue()
898 	 * this push up causes the backshifted finish timestamps of  in bfq_update_fin_time_enqueue()
900 	 * finish timestamps of non weight-raised queues.  in bfq_update_fin_time_enqueue()
923  * Basically, this function updates the timestamps of entity and
982  * present there, 2) updates the timestamps of entity and 3) inserts
984  * the new values of the timestamps).
1002 		 *   reason; the timestamps of the entity need then to  in __bfq_requeue_entity()
1027 		 * the entity according to the new timestamps below.  in __bfq_requeue_entity()
1043 		 * timestamps below. This is the same approach as the  in __bfq_requeue_entity()
1334  * that would influence the timestamps of the entity (e.g., becomes idle,