On 18 May 2018 at 17:19, Martin Hicks <mort@xxxxxxxx> wrote: > > > On Thu, May 17, 2018 at 8:36 PM, Shawn Lin <shawn.lin@xxxxxxxxxxxxxx> wrote: >> >> >> On 2018/5/18 1:53, Martin Hicks wrote: >>> >>> >>> >>> This drastically reduces the rate at which the MMC_SEND_STATUS cmd polls >>> for completion of the MMC Erase operation. On my embedded ARM platform >>> the interrupt rates drop from ~45000/s to ~1000/s, which prevents the >>> system from being very sluggish to respond during Erase operations. >>> >> >> Could you detail the relationship between status polling and why the >> interrupt rates drop(probably with what does the interrupt rate mean)? >> Which host drivers are you using and is that a single core platform? > > > Hi Shawn, > > Yes, this is a single core NXP I.MX6UL with the sdhci-esdhc-imx driver. It > seems that the loop is just sending MMC_SEND_STATUS commands as fast as it > can, and the host gets an interrupt for every command completion. > > For our eMMC each call to mmc_do_erase during an invocation of `blkdiscard > -s /dev/sda` erases 2GB and takes 25-30 seconds to complete. > > I now have second thoughts about this change since the same path is used for > discarding smaller blocks, like if you have "discard" enabled on ext4. > These discard requests can complete very quickly and we wouldn't want to add > latency to these commands. It looks like the "quick" discards can complete > in as little as 50 loops (~1ms), but that would be dependent on the speed of > the MMC bus, as well as how much work the eMMC drive has to do. I fully agree. Several things comes into play, so clearly we needs something a bit more clever than a fixed timeout value. A simplistic approach could be to use a small timeout to start with, then increase it while iterating the loops. Perhaps start by sleeping 128us, then 256, 512, 1024, 2048, 4096. Then we probably want to stop increasing at some point. [...] Kind regards Uffe -- 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
