Date:	Wed, 03 Apr 2013 13:40:46 +0300
From:	Tanya Brokhman <tlinder@...eaurora.org>
To:	Jens Axboe <axboe@...nel.dk>
CC:	linux-mmc@...r.kernel.org, linux-arm-msm@...r.kernel.org,
	Alex.Lemberg@...disk.com, open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v5 2/3] block: Add API for urgent request handling

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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists