XO-1.5 slow disk writes

[Adrian Chadd]

My experience with SD media in general (and I can't test it on XO
systems; I loaned mine out to other testers for the time being) is
that the performance is wildly varied.

It probably doesn't help that the underlying IO is translating as
"read, erase, write" in some cases for lots of sub-flash-"chunk/page"
writes and how that is treated is highly device dependent.

It may be a fun experiment (for values of "fun" that appeal to me at
least) to write some direct-to-device IO tests which experiment with
differing write and erase sizes. Say, try doing random writes of 1k
data in 1k offsets, in 2k offsets, in 4k offsets, etc. Then try 2k
data in the same offsets. See what changes. That may give you some
subtle hints as to what the SD controller is doing.

This is why the idea of buffering IO and doing up a log structured FS
on the consumer flash devices is an interesting prospect, if difficult
to get right. You have this massive disconnect between read and write
IO times, you want to minimise the amount of writing you do but you
absolutely have no issue doing a whole lot of reads.

The actual SSD devices as far as I can gather do a variety of magic to
try and drop the flash erase time from hurting write performance so
much. I cant comment there with any experimental or other authority.

HTH,


Adrian

(ObNote: I've been toying with small object cache stuff on commodity
flash media lately; the above is purely from experiences with that.)

2009/11/18 Daniel Drake <dsd at laptop.org>:
> Hi,
>
> Today I tried to figure out why running "sync" often takes 5-10 seconds
> or longer. This slows down suspend, where all data is synced to disk.
> In all cases that I looked at, the amount of data being synced was tiny.
> One example: in one run it had 160kB data to sync and it took 7.7
> seconds. (blktrace is very handy for figuring this out)
>
> I traced this all the way to the SDHCI driver. These writes are
> typically small and scattered, and our hardware (or the card itself)
> takes a long time to process them. Many of the 1024 byte writes take
> 500-600ms. All other disk I/O is halted during these times. The delay is
> purely after submitting the SDHCI write command, and waiting for the
> completion interrupt to arrive.
>
> I then wrote a C application to reproduce the exact set of writes from a
> 20-second sync that I logged (using random data, but the same sectors,
> sizes and ordering) and reproduced the issue that way.
>
> I also moved the card over to my Dell laptop, ran the same program and
> saw the same (terrible) results.
>
> All info here:
> http://dev.laptop.org/ticket/9688
>
>
> So, I have a feeling that at least with today's generation of miniSD
> cards we're going to be stuck with bad write performance, particularly
> for random-style access like this.
>
> One experiment that would be interesting to run would be to try this on
> one of the PhoenixBIOS boards, and then try it with the exact same SD
> card on a regular XO-1.5. Just in case...
>
> Daniel
>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>
>