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.
I will try to look more into this next week.
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
