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@xxxxxxxxxxxxxx> 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@xxxxxxxxxx> <http://printf.net/> One Laptop Per Child -- 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
