From: andreiw@motorola.com (Andrei Warkentin)
To: linux-arm-kernel@lists.infradead.org
Subject: MMC quirks relating to performance/lifetime.
Date: Fri, 18 Feb 2011 17:17:51 -0600 [thread overview]
Message-ID: <AANLkTimWAnPg2sYiLbfZXAAUiu7P5T3LmNoVbPi9RTEG@mail.gmail.com> (raw)
In-Reply-To: <AANLkTi=rg2Du2RbakqpRNZZ7HHkhrsobz713YL29Wqoi@mail.gmail.com>
2011/2/18 Andrei Warkentin <andreiw@motorola.com>:
> On Fri, Feb 18, 2011 at 1:47 PM, Andrei Warkentin <andreiw@motorola.com> wrote:
>> On Fri, Feb 18, 2011 at 7:44 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>>> I'm curious. Neither the manfid nor the oemid fields of either card
>>> match what I have seen on SD cards, I would expect them to be
>>>
>>> Sandisk: manfid 0x000003, oemid 0x5344
>>> Toshiba: manfid 0x000002, oemid 0x544d
>>>
>>> I have not actually seen any Toshiba SD cards, but I assume that they
>>> use the same controllers as Kingston.
>>>
>>> Does anyone know if the IDs have any correlation between MMC and SD
>>> controllers?
>>>
>>> ? ? ? ?Arnd
>>>
>>
>> I'm unsure about the older scheme (assigned by MMCA), but ever since
>> MMC is now JEDEC-controlled, the IDs have changed. Sandisk's new id
>> will be 0x45, and Toshiba I guess will be 0x11.
>>
>
> Flashbench timings for both Sandisk and Toshiba cards. Attaching due to size.
>
> Some interesting things that I don't understand. For the align test, I
> extended it to do a write align test (-A). I tried two partitions that
> I could write over, and both read and writes behaved differently for
> the two partitions on same device. Odd. They are both 4MB aligned.
>
> On the sandisk it was the write align that made the page size stand
> out. ?The read align had pretty constant results.
>
> On the toshiba the results varied wildly for the two partitions. For
> partition 6, there was a clear pattern in the diff values for read
> align. For 9, it was all over the place. For 9 with the write align,
> 8K and 16K the crossing writes took ~115ms!! Look in attached files
> for all the data.
>
> The AU tests were interesting too, especially how with several open
> AUs the throughput is higher for certain smaller sizes on sandisk, but
> if I interpret it correctly both cards have at least 4 AUs, as I
> didn't see yet a significant drop for small sizes. The larger ones I
> am running now on mmcblk0p9 which is sufficiently larger for these
> tests... (mmcblk0p6 is only 40mb, p9 is 314 mb)
>
> Thanks,
> A
>
I thought this was pretty interesting -
# echo 0 > /sys/block/mmcblk0/device/page_size
# ./flashbench -A -b 1024 /dev/block/mmcblk0p9
write align 8388608 pre 3.59ms on 6.54ms post 3.65ms diff 2.92ms
write align 4194304 pre 4.13ms on 7.37ms post 4.27ms diff 3.17ms
write align 2097152 pre 3.62ms on 6.81ms post 3.94ms diff 3.03ms
write align 1048576 pre 3.62ms on 6.53ms post 3.55ms diff 2.95ms
write align 524288 pre 3.62ms on 6.51ms post 3.63ms diff 2.88ms
write align 262144 pre 3.62ms on 6.51ms post 3.63ms diff 2.89ms
write align 131072 pre 3.62ms on 6.5ms post 3.63ms diff 2.88ms
write align 65536 pre 3.61ms on 6.49ms post 3.62ms diff 2.88ms
write align 32768 pre 3.61ms on 6.49ms post 3.61ms diff 2.88ms
write align 16384 pre 3.68ms on 107ms post 3.51ms diff 103ms
write align 8192 pre 3.74ms on 121ms post 3.91ms diff 117ms
write align 4096 pre 3.88ms on 3.87ms post 3.87ms diff -2937ns
write align 2048 pre 3.89ms on 3.88ms post 3.88ms diff -8734ns
# fjnh84 at fjnh84-desktop:~/src/n/src/flash$ adb -s 17006185428011d7 shell
# echo 8192 > /sys/block/mmcblk0/device/page_size
# cd data
# ./flashbench -A -b 1024 /dev/block/mmcblk0p9
write align 8388608 pre 3.33ms on 6.8ms post 3.65ms diff 3.31ms
write align 4194304 pre 4.34ms on 8.14ms post 4.53ms diff 3.71ms
write align 2097152 pre 3.64ms on 7.31ms post 4.09ms diff 3.44ms
write align 1048576 pre 3.65ms on 7.52ms post 3.65ms diff 3.87ms
write align 524288 pre 3.62ms on 6.8ms post 3.63ms diff 3.17ms
write align 262144 pre 3.62ms on 6.84ms post 3.63ms diff 3.22ms
write align 131072 pre 3.62ms on 6.85ms post 3.44ms diff 3.32ms
write align 65536 pre 3.39ms on 6.8ms post 3.66ms diff 3.28ms
write align 32768 pre 3.64ms on 6.86ms post 3.66ms diff 3.21ms
write align 16384 pre 3.67ms on 6.86ms post 3.65ms diff 3.2ms
write align 8192 pre 3.66ms on 6.84ms post 3.64ms diff 3.19ms
write align 4096 pre 3.71ms on 3.71ms post 3.64ms diff 38.6?s
write align 2048 pre 3.71ms on 3.71ms post 3.72ms diff -656ns
This was with the split unaligned accesses patch... Which I am
attaching for comments.
Thanks,
A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-MMC-Split-non-page-size-aligned-accesses.patch
Type: text/x-diff
Size: 5195 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110218/333fe63e/attachment-0001.bin>
next prev parent reply other threads:[~2011-02-18 23:17 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-08 21:22 MMC quirks relating to performance/lifetime Andrei Warkentin
2011-02-08 21:38 ` Wolfram Sang
2011-02-08 22:42 ` Russell King - ARM Linux
2011-02-09 8:37 ` Linus Walleij
2011-02-09 9:13 ` Arnd Bergmann
2011-02-11 22:33 ` Andrei Warkentin
2011-02-12 17:05 ` Arnd Bergmann
2011-02-12 17:33 ` Andrei Warkentin
2011-02-12 18:22 ` Arnd Bergmann
2011-02-18 1:10 ` Andrei Warkentin
2011-02-18 13:44 ` Arnd Bergmann
2011-02-18 19:47 ` Andrei Warkentin
2011-02-18 22:40 ` Andrei Warkentin
2011-02-18 23:17 ` Andrei Warkentin [this message]
2011-02-19 11:20 ` Arnd Bergmann
2011-02-20 5:56 ` Andrei Warkentin
2011-02-20 15:23 ` Arnd Bergmann
2011-02-22 7:05 ` Andrei Warkentin
2011-02-22 16:49 ` Arnd Bergmann
2011-02-19 9:54 ` Arnd Bergmann
2011-02-20 4:39 ` Andrei Warkentin
2011-02-20 15:03 ` Arnd Bergmann
2011-02-22 6:42 ` Andrei Warkentin
2011-02-22 16:42 ` Arnd Bergmann
2011-02-11 23:23 ` Linus Walleij
2011-02-12 10:45 ` Arnd Bergmann
2011-02-12 10:59 ` Russell King - ARM Linux
2011-02-12 16:28 ` Arnd Bergmann
2011-02-12 16:37 ` Russell King - ARM Linux
2011-02-11 22:27 ` Andrei Warkentin
2011-02-12 18:37 ` Arnd Bergmann
2011-02-13 0:10 ` Andrei Warkentin
2011-02-13 17:39 ` Arnd Bergmann
2011-02-14 19:29 ` Andrei Warkentin
2011-02-14 20:22 ` Arnd Bergmann
2011-02-14 22:25 ` Andrei Warkentin
2011-02-15 17:16 ` Arnd Bergmann
2011-02-17 2:08 ` Andrei Warkentin
2011-02-17 15:47 ` Arnd Bergmann
2011-02-20 11:27 ` Andrei Warkentin
2011-02-20 14:39 ` Arnd Bergmann
2011-02-22 7:46 ` Andrei Warkentin
2011-02-22 17:00 ` Arnd Bergmann
2011-02-23 10:19 ` Andrei Warkentin
2011-02-23 16:09 ` Arnd Bergmann
2011-02-23 22:26 ` Andrei Warkentin
2011-02-24 9:24 ` Arnd Bergmann
2011-02-25 11:02 ` Andrei Warkentin
2011-02-25 12:21 ` Arnd Bergmann
2011-03-01 18:48 ` Jens Axboe
2011-03-01 19:11 ` Arnd Bergmann
2011-03-01 19:15 ` Jens Axboe
2011-03-01 19:51 ` Arnd Bergmann
2011-03-01 21:33 ` Andrei Warkentin
2011-03-02 10:34 ` Andrei Warkentin
2011-03-05 9:23 ` Andrei Warkentin
2011-02-11 14:41 ` Pavel Machek
2011-02-11 14:51 ` Arnd Bergmann
2011-02-11 15:20 ` Lei Wen
2011-02-11 15:25 ` Arnd Bergmann
2011-03-08 6:59 ` Pavel Machek
2011-03-08 14:03 ` Arnd Bergmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AANLkTimWAnPg2sYiLbfZXAAUiu7P5T3LmNoVbPi9RTEG@mail.gmail.com \
--to=andreiw@motorola.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).