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 09:54:54 -0800	[thread overview]
Message-ID: <6934efce0712040954v74cf0b4bk19b49988bc828233@mail.gmail.com> (raw)
In-Reply-To: <20071203230629.725f4c7a@the-village.bc.nu>

> > Has anyone played with this concept?
>
> For things like SATA based devices they aren't that fast yet.

What is fast enough?

As I understand the basic memory technology, the hard limit is in the
100's of microseconds range for latency.  SATA adds something to that.
 I'd be surprised to see latencies on SATA SSD's as measured at the OS
level to get below 1 millisecond.

What happens we start placing NAND technology in lower latency, higher
bandwidth buses?  I'm guessing we'll get down to that 100's of
microseconds level and an order of magnitude higher bandwidth than
SATA.  Is that fast enough to warrant this more synchronous IO?

Magnetic drives have latencies ~10 milliseconds, current SSD's are an
order of magnitude better (~1 millisecond), new interfaces and
refinements could theoretically get us down one more (~100
microsecond).  I'm guessing the current block driver subsystem would
negate a lot of that latency gain.  Am I wrong?

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.

  reply	other threads:[~2007-12-04 17:56 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 [this message]
2007-12-04 20:35     ` Alan Cox
2007-12-04 21:54       ` Jared Hulbert
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=6934efce0712040954v74cf0b4bk19b49988bc828233@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®