Re: [PATCH v2 1/1] mmc: block: replace __blk_end_request() with blk_end_request()

[Chris Ball <cjb@laptop.org>]

Hi Subhash,

On Thu, Jun 07 2012, Subhash Jadavani wrote:
> For completing any block request, MMC block driver is calling:
> 	spin_lock_irq(queue)
> 	__blk_end_request()
> 	spin_unlock_irq(queue)
>
> But if we analyze the sources of latency in kernel using ftrace,
> __blk_end_request() function at times may take up to 6.5ms with
> spinlock held and irq disabled.
>
> __blk_end_request() calls couple of functions and ftrace output
> shows that blk_update_bidi_request() function is almost taking 6ms.
> There are 2 function to end the current request: ___blk_end_request()
> and blk_end_request(). Both these functions do same thing except
> that blk_end_request() function doesn't take up the spinlock
> while calling the blk_update_bidi_request().
>
> This patch replaces all __blk_end_request() calls with
> blk_end_request() and __blk_end_request_all() calls with
> blk_end_request_all().
>
> Testing done: 20 process concurrent read/write on sd card
> and eMMC. Ran this test for almost a day on multicore system
> and no errors observed.
>
> This change is not meant for improving MMC throughput; it's basically
> about becoming fair to other threads/interrupts in the system. By holding
> spin lock and interrupts disabled for longer duration, we won't allow
> other threads/interrupts to run at all.
> Actually slight performance degradation at file system level can be expected
> as we are not holding the spin lock during blk_update_bidi_request() which
> means our mmcqd thread may get preempted for other high priority thread or
> any interrupt in the system.
>
> These are performance numbers (100MB file write) with eMMC running in DDR
> mode:
>
> Without this patch:
> 	Name of the Test   Value   Unit
> 	LMDD Read Test     53.79   MBPS
> 	LMDD Write Test    18.86   MBPS
> 	IOZONE  Read Test  51.65   MBPS
> 	IOZONE  Write Test 24.36   MBPS
>
> With this patch:
> 	Name of the Test    Value  Unit
> 	LMDD Read Test      52.94  MBPS
> 	LMDD Write Test     16.70  MBPS
> 	IOZONE  Read Test   52.08  MBPS
> 	IOZONE  Write Test  23.29  MBPS
>
> Read numbers are fine. Write numbers are bit down (especially LMDD write),
> may be because write requests normally have large transfer size and
> which means there are chances that while mmcq is executing
> blk_update_bidi_request(), it may get interrupted by interrupts or
> other high priority thread.
>
> Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>

Thanks very much for doing this, and for the detailed commit message --
pushed to mmc-next with Namjae's Reviewed-by.

- Chris.
-- 
Chris Ball   <cjb@laptop.org>   <http://printf.net/>
One Laptop Per Child