block, bfq: fix some typos in comments

	},

#endif /* CONFIG_DEBUG_BLK_CGROUP */

	/* the same statictics which cover the bfqg and its descendants */

	/* the same statistics which cover the bfqg and its descendants */

	{

		.name = "bfq.io_service_bytes_recursive",

		.private = (unsigned long)&blkcg_policy_bfq,

/*

 * When a sync request is dispatched, the queue that contains that

 * request, and all the ancestor entities of that queue, are charged

 * with the number of sectors of the request. In constrast, if the

 * with the number of sectors of the request. In contrast, if the

 * request is async, then the queue and its ancestor entities are

 * charged with the number of sectors of the request, multiplied by

 * the factor below. This throttles the bandwidth for async I/O,

 * queue merging.

 *

 * As can be deduced from the low time limit below, queue merging, if

 * successful, happens at the very beggining of the I/O of the involved

 * successful, happens at the very beginning of the I/O of the involved

 * cooperating processes, as a consequence of the arrival of the very

 * first requests from each cooperator.  After that, there is very

 * little chance to find cooperators.

/*

 * Lifted from AS - choose which of rq1 and rq2 that is best served now.

 * We choose the request that is closesr to the head right now.  Distance

 * We choose the request that is closer to the head right now.  Distance

 * behind the head is penalized and only allowed to a certain extent.

 */

static struct request *bfq_choose_req(struct bfq_data *bfqd,

	 *   of several files

	 * mplayer took 23 seconds to start, if constantly weight-raised.

	 *

	 * As for higher values than that accomodating the above bad

	 * As for higher values than that accommodating the above bad

	 * scenario, tests show that higher values would often yield

	 * the opposite of the desired result, i.e., would worsen

	 * responsiveness by allowing non-interactive applications to

		/*

		 * bic still points to bfqq, then it has not yet been

		 * redirected to some other bfq_queue, and a queue

		 * merge beween bfqq and new_bfqq can be safely

		 * fulfillled, i.e., bic can be redirected to new_bfqq

		 * merge between bfqq and new_bfqq can be safely

		 * fulfilled, i.e., bic can be redirected to new_bfqq

		 * and bfqq can be put.

		 */

		bfq_merge_bfqqs(bfqd, bfqd->bio_bic, bfqq,

	/*

	 * All in-service entities must have been properly deactivated

	 * or requeued before executing the next function, which

	 * resets all in-service entites as no more in service.

	 * resets all in-service entities as no more in service.

	 */

	__bfq_bfqd_reset_in_service(bfqd);

}

 * preparation is that, after the prepare_request hook is invoked for

 * rq, rq may still be transformed into a request with no icq, i.e., a

 * request not associated with any queue. No bfq hook is invoked to

 * signal this tranformation. As a consequence, should these

 * signal this transformation. As a consequence, should these

 * preparation operations be performed when the prepare_request hook

 * is invoked, and should rq be transformed one moment later, bfq

 * would end up in an inconsistent state, because it would have

 * expiration. This peculiar definition allows for the following

 * optimization, not yet exploited: while a given entity is still in

 * service, we already know which is the best candidate for next

 * service among the other active entitities in the same parent

 * service among the other active entities in the same parent

 * entity. We can then quickly compare the timestamps of the

 * in-service entity with those of such best candidate.

 *

 *

 * Unless cgroups are used, the weight value is calculated from the

 * ioprio to export the same interface as CFQ.  When dealing with

 * ``well-behaved'' queues (i.e., queues that do not spend too much

 * "well-behaved" queues (i.e., queues that do not spend too much

 * time to consume their budget and have true sequential behavior, and

 * when there are no external factors breaking anticipation) the

 * relative weights at each level of the cgroups hierarchy should be

 * bfq_update_next_in_service - update sd->next_in_service

 * @sd: sched_data for which to perform the update.

 * @new_entity: if not NULL, pointer to the entity whose activation,

 *		requeueing or repositionig triggered the invocation of

 *		requeueing or repositioning triggered the invocation of

 *		this function.

 * @expiration: id true, this function is being invoked after the

 *             expiration of the in-service entity

	/*

	 * If this update is triggered by the activation, requeueing

	 * or repositiong of an entity that does not coincide with

	 * or repositioning of an entity that does not coincide with

	 * sd->next_in_service, then a full lookup in the active tree

	 * can be avoided. In fact, it is enough to check whether the

	 * just-modified entity has the same priority as

 * In this first case, update the virtual time in @st too (see the

 * comments on this update inside the function).

 *

 * In constrast, if there is an in-service entity, then return the

 * In contrast, if there is an in-service entity, then return the

 * entity that would be set in service if not only the above

 * conditions, but also the next one held true: the currently

 * in-service entity, on expiration,

		 * is being invoked as a part of the expiration path

		 * of the in-service queue. In this case, even if

		 * sd->in_service_entity is not NULL,

		 * sd->in_service_entiy at this point is actually not

		 * sd->in_service_entity at this point is actually not

		 * in service any more, and, if needed, has already

		 * been properly queued or requeued into the right

		 * tree. The reason why sd->in_service_entity is still

		 * not NULL here, even if expiration is true, is that

		 * sd->in_service_entiy is reset as a last step in the

		 * sd->in_service_entity is reset as a last step in the

		 * expiration path. So, if expiration is true, tell

		 * __bfq_lookup_next_entity that there is no

		 * sd->in_service_entity.