> -----Original Message----- > From: Arnd Bergmann [mailto:arnd@xxxxxxxx] > Sent: Sunday, February 13, 2011 2:05 AM > To: Dong, Chuanxiao > Cc: linux-mmc@xxxxxxxxxxxxxxx; cjb@xxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; > akpm@xxxxxxxxxxxxxxxxxxxx; adrian.hunter@xxxxxxxxx > Subject: Re: [PATCH v4 1/3]mmc: set max_discard_sectors value for mmc queue > > 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. Thanks, Arnd. When I do trim with a 32GB eMMC card in my platform, sometimes I can get the 10s timeout errors but sometimes not. I am not much clear about the "discarding partial AU will take a lot longer". If this action is hide for driver, then I think from driver side, the UINT_MAX value for max_discard_sectors will be OK. But if this action sometimes need driver to wait for some hardware interrupt, then I think the UINT_MAX value is not preferred. Arnd, have any suggestion of dealing this? What I thought is using other value instead of using UINT_MAX. Thanks Chuanxiao -- 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
