fio infrastructure

I really wish I could have tested this with working hardware, but the gods are against that idea. So here is a patch anyway.

Main idea is to have three asynchonous operations for read, write and erase. The old erase method already has an asynchronous interface, so arguably I could have reused that. But for consistency and because no existing driver actually worked asynchronously, I decided to add a new method for erase as well.

Each operation works on the smallest possible entity - either a page or a block. If and when hardware arrives that performs better when using larger operations, we can still change that.

The wait_multiple_* code is can be used to send off a lot of IO at once and wait for it all to finish.

Comments?

Jörn

To my face you have the audacity to advise me to become a thief - the worst
kind of thief that is conceivable, a thief of spiritual things, a thief of
ideas! It is insufferable, intolerable!
-- M. Binet in Scarabouche

FIO or Flash IO is loosely based on bio.  Like bios, fios are
asynchronous and can be queued, reordered, etc.  Unlike bios, fios are
tiny operations - single page read, single page write, single block
erase.  To group larger operations, the wait_multiple infrastructure
can be used.
---
 drivers/mtd/mtdcore.c   |   25 +++++++++++++++++++++++
 include/linux/mtd/mtd.h |   51 +++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 76 insertions(+), 0 deletions(-)

index 467a4f1..04ac1a0 100644
@@ -44,6 +44,31 @@ EXPORT_SYMBOL_GPL(mtd_table);
 static LIST_HEAD(mtd_notifiers);
 
 
+void wait_multiple_init(struct wait_multiple *wm_data, int count)
+{
+	kref_set(&wm_data->refcount, count);
+	init_completion(&wm_data->complete);
+	wm_data->err = 0;
+}
+
+void wait_multiple_release(struct kref *kref)
+{
+	struct wait_multiple *wm_data;
+
+	wm_data = container_of(kref, struct wait_multiple, refcount);
+	complete(&wm_data->complete);
+}
+
+void wait_multiple_complete(struct fio *fio)
+{
+	struct wait_multiple *wm_data = fio->fi_private;
+
+	if (fio->fi_err && !wm_data->err)
+		wm_data->err = fio->fi_err;
+	kref_put(&wm_data->refcount, wait_multiple_release);
+	free_fio(fio);
+}
+
 #if defined(CONFIG_MTD_CHAR) || defined(CONFIG_MTD_CHAR_MODULE)
 #define MTD_DEVT(index) MKDEV(MTD_CHAR_MAJOR, (index)*2)
 #else

1.6.2.1

In theory this could address some problems I was contemplating earlier today. If Jörn vision of large scale flash storage device without the added FTL overhead is to realized, we'll need this sort of thing. For that matter, take the Atom processor line, aren't the newer ones planning on raw NAND access built in? If you want to get the performance a several NAND chips can enable you'd need something like this, no?

What is needed, bare minimum, to test this? Is access to multiple bare NAND chips enough?

I cannot comment on processor lines, Atom or otherwise. But afaics the only alternative to asynchronous operations would be striping. Disadvantage of striping is that erase block size (and potentially page size) increases and bad block in one stripe poison good blocks in all other stripes. Not too appealing to me.

Plus, you can get all the benefits from striping with fio as well.

Yes.

Jörn

Premature optimization is the root of all evil.
-- Donald Knuth