linux-kernel - RE: [PATCH v4 1/3]mmc: set max_discard

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5D8008F58939784290FAB48F5497519835964E1F58@shsmsx502.ccr.corp.intel.com>
Date:	Mon, 14 Feb 2011 15:01:35 +0800
From:	"Dong, Chuanxiao" <chuanxiao.dong@...el.com>
To:	Arnd Bergmann <arnd@...db.de>
CC:	"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
	"cjb@...top.org" <cjb@...top.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"adrian.hunter@...ia.com" <adrian.hunter@...ia.com>
Subject: RE: [PATCH v4 1/3]mmc: set max_discard_sectors value for mmc queue

> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd@...db.de]
> Sent: Sunday, February 13, 2011 2:05 AM
> To: Dong, Chuanxiao
> Cc: linux-mmc@...r.kernel.org; cjb@...top.org; linux-kernel@...r.kernel.org;
> akpm@...ux-foundation.org; adrian.hunter@...ia.com
> 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@...db.de]
> > > 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@...el.com>
> > >
> > > 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/