On 24 May 2018 at 11:05, Shawn Lin <shawn.lin@xxxxxxxxxxxxxx> wrote: > > On 2018/5/21 16:22, Ulf Hansson wrote: >> >> 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 have a question why mmc_do_erase re-invent the wheel but not using > mmc_poll_for_busy. If that's possible, sdhci-esdhc-imx.c could use > ->card_busy() callback defined in sdhci.c, which could solve your > problem, as mmc_poll_for_busy will try to use card_busy(). Then > relinguish sched in mmc_poll_for_busy properly will slove > other potention similar problems using on single core platform. It's a great idea, we should look into if that makes sense. Then mmc_poll_for_busy, also should cover the rpmb ioctl case (which also has its own loop). > > I will try to look more into this next week. Great! At the same time, I think Martin can continue his work, nothing prevent us from merging the changes into the mmc_poll_for_busy as a second step. [...] 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
