On Saturday 12 February 2011 11:42:51 Dong, Chuanxiao wrote: > > From: Arnd Bergmann [mailto:arnd@xxxxxxxx] > > On Saturday 12 February 2011 07:22:14 Chuanxiao Dong wrote: > > > max_discard_sectors value is UINT_MAX which means kernel block layer can pass > > > down unlimited sectors to MMC driver to erase. But erasing so many sectors may > > > delay some other important I/O requests. This is not preferred. > > > > > > So use 'pref_erase' to set a suitable max_discard_sectors value for mmc queue to > > > avoid erasing too many sectors at one time. > > > > > > Signed-off-by: Chuanxiao Dong <chuanxiao.dong@xxxxxxxxx> > > > > I'm not sure about this one. pref_erase on SDHC cards should be the *minimum* > > unit you can erase in one request, not the maximum. Erasing an arbitrary > > I found the comment in mmc_init_erase() function which explains the 'pref_erase': > 'pref_erase' is defined as a guide to limit erases to that size and alignment. > So I think it is not the minimum unit driver can erase, also not the maximum > erase unit. It just a guide erase size for driver which can avoid holding host > controller too long to response other I/O requests. Ok, I see. Adrian introduced the function and the comment last year, maybe he can comment on this some more. For all cards I've seen, multi-AU erases on SDHC cards are really fast, though the standard clearly allows for very slow erases. My feeling is that the function is suboptimal right now, because it assumes that one AU is the best size. If a card reports that it can erase many AUs quickly (large N_erase, small T_erase, relatively large T_offset), we should report that to the user. > > number of allocation units on an SDHC card should complete almost instantly, > > because it only needs to update a single table with the allocation units. > > > > Discarding partial allocation units will take a lot longer, because the > > card then has to copy over the remaining blocks. > > Is discarding started when card is idle or right after erase command? > Can it cause some other I/O requests delayed? As far as I can tell, most operations on the card are synchronous when it's writing. The erase command on a partial AU should not return until the remaining data is copied to a new location, so it will take some time, but physically the AU can be done in the background, if reading from it simply returns a zero buffer rather than accessing the old data. Write-after-erase might have to wait for the erase to complete, but good cards could also hide that. Arnd -- 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
