RE: [PATCH v4 1/3]mmc: set max_discard_sectors value for mmc queue

[Dong, Chuanxiao]

> -----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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/