Thread (62 messages) 62 messages, 9 authors, 2011-03-08

MMC quirks relating to performance/lifetime.

From: arnd@arndb.de (Arnd Bergmann)
Date: 2011-02-15 17:16:56
Also in: linux-mmc

On Monday 14 February 2011, Andrei Warkentin wrote:
quoted
There are multiple ways how this could be implemented:

1. Have one exception cache for all "special" blocks. This would normally
  be for FAT32 subdirectory updates, which always write to the same
  few blocks. This means you can do small writes efficiently anywhere
  on the card, but only up to a (small) fixed number of block addresses.
  If you overflow the table, the card still needs to go through an
  extra PE for each new entry you write, in order to free up an entry.

2. Have a small number of AUs that can be in a special mode with efficient
  small writes but inefficient large writes. This means that when you
  alternate between small and large writes in the same AU, it has to go
  through a PE on every switch. Similarly, if you do small writes to
  more than the maximum number of AUs that can be held in this mode, you
  get the same effect. This number can be as small as one, because that
  is what FAT32 requires.

In both cases, you don't actually have a solution for the problem, you just
make it less likely for specific workloads.
Aha, ok. By the way, I did find out that either suggestion works. So
I'll pull out the reversing portion of the patch. No need to
overcomplicate :).
BTW, what file system are you using? I could imagine that each of ext4, btrfs
and nilfs2 give you very different results here. It could be that if your
patch is optimizing for one file system, it is actually pessimising for
another one.

What benchmark do you use to find out of your optimizations actually help you?

	Arnd
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help