mtd_info->size again (lengthy)

[Jörn Engel]

On Mon, 9 June 2008 17:31:49 +0100, Jamie Lokier wrote:
> 
> > But mtdio is even worse.  Dude, what are you smoking? ;)
> 
> submit_fio suggests "file I/O" to me....  Even if I knew better, it
> looks just that bit too much like submit_bio for something file-ish.
> 
> submit_mtd_request or async_mtd, then! :-)

No, the similarities to submit_bio are _not_ accidental.  In a perfect
world, I would have used submit_bio.  In our less than perfect world, I
want to retain as many similarities as possible.  We have two storage
subsystems in the kernel that have lived their own seperate lives for
all too long.  They should get combined by some brave soul.  And while I
am not that brave soul, at least I can make his/her work a little
easier.

> I didn't say it's a _good_ idea!  Just that I won't be surprised when
> someone produces hardware like that.  And, there will probably be a
> reason you haven't thought of why they did it that way.

If someone is stupid enough to create such hardware, I don't mind if
they suffer.  Quite the contrary.  Send them the darwin award of
hardware engineering!

> > Part of the reason for asynchronous interfaces is to make parallel chips
> > work fast without striping them.  Or rather, make them work even faster
> > than stripes.
> 
> And erasing simultaneous with streaming writes, let the CPU get on
> with something else, etc.

Same with asynchronous erases on all chips - except that the blocks
being erased don't need any special relationship.

> What should the behaviour be with devices which block the CPU during
> synchronous writes and erases?  Right now, you can be sure the
> temporary CPU blockage (if there is one) happens when you request the
> I/O.  If it's asynchronous, depending on how it's implemented, the CPU
> could block at an unexpected time later.

Good devices should have a dma engine and an interrupt line.  Lesser
devices can set a timer in the driver.  If the cpu has to actively do
some work during erase, you won't win any benchmark crowns with it
anyway and I care fairly little.

If you are designing hardware and want it to be fast, make sure it can
handle at least one request autonomously.  Better yet add a small queue
with - say - 16 entries and simply handle them in order.  Reads/writes
should dma the data to/from main memory.  Each completed request yields
an interrupt.

This is not rocket science.  If you have any trouble implementing
something like this, just talk to some network/ide/scsi person.  Crap
design like dual plane chips will disappear over time.  Once you get to
64 parallel planes, it is obvious that the same approach no longer
works.

Jörn

-- 
Doubt is not a pleasant condition, but certainty is an absurd one.
-- Voltaire