mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Jared Hulbert" <jaredeh@gmail.com>
To: "Alan Cox" <alan@lxorguk.ukuu.org.uk>
Cc: "Chris Friesen" <cfriesen@nortel.com>, linux-kernel@vger.kernel.org
Subject: Re: solid state drive access and context switching
Date: Tue, 4 Dec 2007 13:54:21 -0800	[thread overview]
Message-ID: <6934efce0712041354n47c11d6ckbc7f4aa1e7c85f@mail.gmail.com> (raw)
In-Reply-To: <20071204203536.2bf6d025@the-village.bc.nu>

> > microseconds level and an order of magnitude higher bandwidth than
> > SATA.  Is that fast enough to warrant this more synchronous IO?
>
> See the mtd layer.

Right.  The trend is to hide the nastiness of NAND technology changes
behind controllers.  In general I think this is a good thing.
Basically the changes in ECC and reliability change very rapidly in
this technology.  Having custom controller hardware to handle this is
faster than handling it in software and makes for a nice modular
interface.  We don't rewrite our SATA drivers and filesystem
everything the magnetic media switches to a new recording scheme, we
just plug it in.  SSD's are going to be like that even if they aren't
SATA. However, the MTD layer is more about managing the chips
themselves, which is what the controllers are for.

Maybe I'm missing something but I don't see it.  We want a block
interface for these devices, we just need a faster slimmer interface.
Maybe a new mtdblock interface that doesn't do erase would be the
place for?

> > BTW - This trend toward faster, lower latency busses is marching
> > forward.  2 examples; the ioDrive from Fusion IO, Micron's RAM-module
> > like SSD concept.
>
> Very much so but we can do quite a bit in 10,000 processor cycles ...
>
> Alan
>

  reply	other threads:[~2007-12-04 21:54 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-03 23:06 Chris Friesen
2007-12-03 23:06 ` Alan Cox
2007-12-04 17:54   ` Jared Hulbert
2007-12-04 20:35     ` Alan Cox
2007-12-04 21:54       ` Jared Hulbert [this message]
2007-12-04 22:45         ` Jörn Engel
2007-12-05  0:03           ` Jared Hulbert
2007-12-04 23:24         ` Alan Cox
2007-12-05  0:08           ` Jared Hulbert
2007-12-05  0:24             ` Alan Cox
2007-12-05 22:01               ` Jared Hulbert
2007-12-06  3:51                 ` Kyungmin Park
2007-12-04 20:46     ` Chris Friesen
2007-12-04 21:38       ` Jared Hulbert
2007-12-04 20:52   ` Jeff Garzik
2007-12-04 21:02     ` Alan Cox
     [not found] <fa.4uUCLsuQFjc4FtQYCBYK6kY9TiU@ifi.uio.no>
2007-12-05  1:11 ` Robert Hancock

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=6934efce0712041354n47c11d6ckbc7f4aa1e7c85f@mail.gmail.com \
    --to=jaredeh@gmail.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=cfriesen@nortel.com \
    --cc=linux-kernel@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

all inboxes | Powered by JetHome®