public inbox for linux-mmc@vger.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Andrei Warkentin <andreiw@motorola.com>
Cc: linux-arm-kernel@lists.infradead.org,
	Linus Walleij <linus.walleij@linaro.org>,
	linux-mmc@vger.kernel.org
Subject: Re: MMC quirks relating to performance/lifetime.
Date: Sat, 19 Feb 2011 10:54:48 +0100	[thread overview]
Message-ID: <201102191054.48706.arnd@arndb.de> (raw)
In-Reply-To: <AANLkTi=rg2Du2RbakqpRNZZ7HHkhrsobz713YL29Wqoi@mail.gmail.com>

On Friday 18 February 2011 23:40:16 Andrei Warkentin wrote:
> On Fri, Feb 18, 2011 at 1:47 PM, Andrei Warkentin <andreiw@motorola.com> wrote:
>
> Flashbench timings for both Sandisk and Toshiba cards. Attaching due to size.

Very nice, thanks for the measurement!

I don't think having the results inline in the mail is a problem,
it would even make it easier to quote.
 
> 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.

I never did a write align test because the results will be highly
unreliable as soon as you get into thrashing. Your results seem
to be meaningful still, so maybe we should have it after all, but
I'll put a big warning on it.

> On the sandisk it was the write align that made the page size stand
> out.  The read align had pretty constant results.

I've noticed on other Sandisk media that the read align test is
sometimes useless. It may help to do a full erase of the partition,
or to fill it with data before running the test.

> 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.

Partition 6 is a lot smaller, so you have the accesses less than a
segment apart, so it shows other effects.

> 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)

Right, you should try larger values for --open-au-nr here. It's at
least a good sign that the drive can do random access inside a segment
and that it can have at least 4 segments open. This is much better
than I expected from your descriptions at first.

However, the drop from 32 KB to 16 KB in performance is horrifying
for the Toshiba drive, it's clear that this one does not like
to be accessed smaller than 32 KB at a time, an obvious optimization
for FAT32 with 32 KB clusters. How does this change with your
kernel patches?

For the sandisk drive, it's funny how it is consistently faster
doing random access than linear access. I don't think I've seem that
before. It does seem to have some cache for linear access using
smaller than 16 KB, and can probably combine them when it's only
writing to a single segment.

	Arnd

  parent reply	other threads:[~2011-02-19  9:55 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <AANLkTikh4vfS7SLKAa-aUXhbTxcHzYHmBuaXj1qHHYN9@mail.gmail.com>
2011-02-08 21:38 ` MMC quirks relating to performance/lifetime Wolfram Sang
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
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 [this message]
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
     [not found] ` <201102111551.15508.arnd@arndb.de>
     [not found]   ` <20110308065911.GC1357@ucw.cz>
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=201102191054.48706.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=andreiw@motorola.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-mmc@vger.kernel.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