Re: SET_BLOCK_COUNT-bounded multiblock transfers

[Andrei Warkentin <andreiw@motorola.com>]

+Arindam (This is the patch set I mentioned)

On Fri, Apr 15, 2011 at 2:10 AM, Andrei Warkentin <andreiw@motorola.com> wrote:
> On Thu, Apr 14, 2011 at 6:18 PM, Chris Ball <cjb@laptop.org> wrote:
>>
>> If we've seen a card that freaks out and loses significant bandwidth, that
>> would be a good reason to start with a whitelist.  If all the data we have
>> suggests that it's performance-wise either a win or a no-op, that's a fine
>> reason to push it to mmc-next with a blacklist approach and change our
>> minds later if our knowledge gets updated.  Does that help?
>>
>
> Yes, it does, thanks! Basically so far -
>
> (a) amazing boost for Sandisk eMMCs
> (b) synthetic tests showed no-op for Toshiba (a derivative of Arnd's
> flashbench, I'll put it up on GitHub as soon as my hands get to it),
> but more realistic test (via SQLite transactions on top of fs) showed
> slight deterioration. I'm bringing it up with the vendor to get a
> clear picture why and if they are doing anything to address it.
> (c) I am going to try to dig up some discrete MMCs (hard beasts to
> come by these days) and try with that.
> (d) I am going to dig up a few SDXCs and try them out.
>
> My current theory is that the CMD23 for multiblock should have no
> effect on the really braindead cards, and could have deterioration on
> cards that somehow optimize the CMD12 path (for example, the T eMMC
> optimize consecutive multiblock writes).
>
> At any rate, I'll decouple CMD23 support from multiblock CMD23 use...
>
> Yunpeng, I'm curious, what vendors did you have in mind when you
> suggested in your original email to use the CMD23 multiblock stuff?
>
> Thanks again,
> A
>