MMC quirks relating to performance/lifetime.
Andrei Warkentin
andreiw at motorola.com
Tue Feb 8 16:22:59 EST 2011
Hi,
I'm not sure if this is the best place to bring this up, but Russel's
name is on a fair share of drivers/mmc code, and there does seem to be
quite a bit of MMC-related discussions. Excuse me in advance if this
isn't the right forum :-).
Certain MMC vendors (maybe even quite a bit of them) use a pretty
rigid buffering scheme when it comes to handling writes. There is
usually a buffer A for random accesses, and a buffer B for sequential
accesses. For certain Toshiba parts, it looks like buffer A is 8KB
wide, with buffer B being 4MB wide, and all accesses larger than 8KB
effectively equating to 4MB accesses. Worse, consecutive small (8k)
writes are treated as one large sequential access, once again ending
up in buffer B, thus necessitating out-of-order writing to work around
this.
What this means is decreased life span for the parts, and it also
means a performance impact on small writes, but the first item is much
more crucial, especially for smaller parts.
As I've mentioned, probably more vendors are affected. How about a
generic MMC_BLOCK quirk that splits the requests (and optionally
reorders) them? The thresholds would then be adjustable as
module/kernel parameters based on manfid. I'm asking because I have a
patch now, but its ugly and hardcoded against a specific manufacturer.
Thanks,
A
More information about the linux-arm-kernel
mailing list