On 11/05/2012 08:20 AM, Per Förlin wrote: > Hi Konstantin, > > On 11/01/2012 03:40 PM, Konstantin Dorfman wrote: >> When current request is running on the bus and if next request fetched >> by mmcqd is NULL, mmc context (mmcqd thread) gets blocked until the >> current request completes. This means if new request comes in while >> the mmcqd thread is blocked, this new request can not be prepared in >> parallel to current ongoing request. This may result in latency to >> start new request. >> >> This change allows to wake up the MMC thread (which >> is waiting for the current running request to complete). Now once the >> MMC thread is woken up, new request can be fetched and prepared in >> parallel to current running request which means this new request can >> be started immediately after the current running request completes. >> >> With this change read throughput is improved by 16%. > What HW and what test cases have you been running? I use the msm_sdcc controller and ran lmdd, tiotest, iozone benchmark tool (details were on other mail in this thread). I ran it on Qualcomm® SnapdragonT S4 ProAPQ8064 Thanks, -- Konstantin Dorfman, 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
