Hi. Subhash. Would you share which option you used in LMDD, iozone test ? Thanks. 2012/4/18 Subhash Jadavani <subhashj@xxxxxxxxxxxxxx>: > Hi Chris, > >> -----Original Message----- >> From: linux-arm-msm-owner@xxxxxxxxxxxxxxx [mailto:linux-arm-msm- >> owner@xxxxxxxxxxxxxxx] On Behalf Of Subhash Jadavani >> Sent: Wednesday, April 11, 2012 12:22 AM >> To: 'Chris Ball' >> Cc: linux-mmc@xxxxxxxxxxxxxxx; linux-arm-msm@xxxxxxxxxxxxxxx >> Subject: RE: [PATCH v1 1/1] mmc: block: replace __blk_end_request() with >> blk_end_request() >> >> >> >> > -----Original Message----- >> > From: Chris Ball [mailto:cjb@xxxxxxxxxx] >> > Sent: Wednesday, April 11, 2012 12:08 AM >> > To: Subhash Jadavani >> > Cc: linux-mmc@xxxxxxxxxxxxxxx; linux-arm-msm@xxxxxxxxxxxxxxx >> > Subject: Re: [PATCH v1 1/1] mmc: block: replace __blk_end_request() >> > with >> > blk_end_request() >> > >> > Hi, >> > >> > On Tue, Apr 10 2012, Subhash Jadavani wrote: >> > > 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. >> > >> > Is there a measurable improvement in throughput or latency that you >> > can >> show >> > data for? >> >> This change was 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. > > Any thoughts/suggestions on this patch and numbers? > > Regards, > Subhash >> >> Regards, >> Subhash >> >> > >> > Thanks, >> > >> > - Chris. >> > -- >> > Chris Ball <cjb@xxxxxxxxxx> <http://printf.net/> >> > One Laptop Per Child >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" > in the >> body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at >> http://vger.kernel.org/majordomo-info.html > > -- > 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 -- 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
