Re: [PATCH v5 2/3] block: Add API for urgent request handling

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 3/25/2013 2:40 PM, Jens Axboe wrote:
On Mon, Mar 25 2013, Tanya Brokhman wrote:
This patch add support in block & elevator layers for handling
urgent requests. The decision if a request is urgent or not is taken
by the scheduler. Request is marked as urgent in cmd_flags (by the
scheduler) with a new flag - REQ_URGENT.
Urgent request notification is passed to the underlying
block device driver (eMMC for example). Block device driver may decide to
interrupt the currently running low priority request to serve the new
urgent request. By doing so READ latency is greatly reduced in read&write
collision scenarios.

Note that if the current scheduler doesn't implement the urgent request
mechanism, this code path is never activated.
I really don't like this out-of-band mechanism. Lets say there is an
urgent request, the IO scheduler would put that at the head of the
queue. So the first time the driver fetches a request, it'll see this
urgent request. A driver that has support for this, would check the head
of queue everytime its request_fn was invoked. There's no need to add a
elevator_is_urgent_fn() and ->notified_urgent.

Hi Jens,

Thank you for your inputs. We implemented the URGENT request notification in block layer with elevator_is_urgent_fn() and ->notified_urgent due to the following:

1. In the future the URGENT request mechanism may be of use to other block device drivers besides mmc (such as sdcc for example). Having this mechanism in the block layer spares all of the block devices re-implementing it.

2. Using the existing API (->request_fn() and not urgent_request->fn()) won’t work as intended for URGENT requests in case the block device already handles 2 requests. In such a case, when a device driver will peek the dispatch queue to check if an URGENT request is pending or not, a new request will be dispatched. If an URGENT requests is inserted to the scheduler after that, the block device will not be aware of its existence, which will result in high latency for this URGENT request. For example:

The device driver is currently handling requests regular_A and regular_B when a new regular request ( regular_C ) arrives and ->request_fn() is called by the block layer. The device driver ”peeks” the dispatch queue in order to find out if there is an URGENT request pending. The I/O scheduler will insert regular_C into the dispatch queue, the device driver will see that there is no URGNET request pending and continue its work. Regular_C will remain pending on the dispatch queue. Now another request arrives: URGENT_D and ->request_fn() is called again. But this time when the device driver “peeks” the dispatch queue to find if an URGENT request is pending it will look at regular_C and URGENT_D will remain in the scheduler data base till regular_A and regular_B requests are completed and regular_C is sent to the card.

The ->notified_urgent is needed because we don’t want to notify the device driver of an URGENT request if there is already an URGENT request in flight. This is because we don’t want URGENT requests to be interrupted.

--

QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center, Inc. is a member

of Code Aurora Forum, hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux