Hi,
On Dec 6, 2007 7:01 AM, Jared Hulbert <[EMAIL PROTECTED]> wrote:
> > Probably about 1000 clocks but its always going to depend upon the
> > workload and whether any other work can be done usefully.
>
> Yeah. Sounds right, in the microsecond range. Be interesting to see data.
>
> Anybody
> Probably about 1000 clocks but its always going to depend upon the
> workload and whether any other work can be done usefully.
Yeah. Sounds right, in the microsecond range. Be interesting to see data.
Anybody have ideas on what kind of experiments could confirm this
estimate is right?
--
To
Probably about 1000 clocks but its always going to depend upon the
workload and whether any other work can be done usefully.
Yeah. Sounds right, in the microsecond range. Be interesting to see data.
Anybody have ideas on what kind of experiments could confirm this
estimate is right?
--
To
Hi,
On Dec 6, 2007 7:01 AM, Jared Hulbert [EMAIL PROTECTED] wrote:
Probably about 1000 clocks but its always going to depend upon the
workload and whether any other work can be done usefully.
Yeah. Sounds right, in the microsecond range. Be interesting to see data.
Anybody have ideas on
Chris Friesen wrote:
Over on comp.os.linux.development.system someone asked an interesting
question, and I thought I'd mention it here.
Given a fast low-latency solid state drive, would it ever be beneficial
to simply wait in the kernel for synchronous read/write calls to
complete? The
On Tue, 4 Dec 2007 16:08:07 -0800
"Jared Hulbert" <[EMAIL PROTECTED]> wrote:
> On Dec 4, 2007 3:24 PM, Alan Cox <[EMAIL PROTECTED]> wrote:
> > > Right. The trend is to hide the nastiness of NAND technology changes
> > > behind controllers. In general I think this is a good thing.
> >
> > You
On Dec 4, 2007 3:24 PM, Alan Cox <[EMAIL PROTECTED]> wrote:
> > Right. The trend is to hide the nastiness of NAND technology changes
> > behind controllers. In general I think this is a good thing.
>
> You miss the point - any controller you hide it behind almost inevitably
> adds enough latency
> > 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?
>
> Doesn't do erase? MTD has to learn almost all tricks from the
> Right. The trend is to hide the nastiness of NAND technology changes
> behind controllers. In general I think this is a good thing.
You miss the point - any controller you hide it behind almost inevitably
adds enough latency you don't want to use it synchronously.
Alan
--
To unsubscribe
On Tue, 4 December 2007 13:54:21 -0800, Jared Hulbert wrote:
>
> 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?
Doesn't do
> > 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.
> > refinements could theoretically get us down one more (~100
> > microsecond).
>
> They've already done already better than that. Here's a solid state
> drive with a claimed 20 microsecond access time:
>
> http://www.curtisssd.com/products/drives/hyperxclr
Right. That looks to be RAM based,
On Tue, 04 Dec 2007 15:52:20 -0500
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Alan Cox wrote:
> > For things like SATA based devices they aren't that fast yet.
>
> You forget the Gigabyte i-RAM.
>
> For others: the i-RAM is a SATA-based device that plugs into a PCI slot
> on your motherboard
Alan Cox wrote:
For things like SATA based devices they aren't that fast yet.
You forget the Gigabyte i-RAM.
For others: the i-RAM is a SATA-based device that plugs into a PCI slot
on your motherboard (for power), providing RAM+battery backup as fast as
your SATA bus and DIMMs will go.
Jared Hulbert wrote:
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).
They've already done already better than that. Here's a solid
> 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.
> BTW - This trend toward faster, lower latency busses is marching
> forward. 2 examples; the ioDrive from Fusion IO, Micron's RAM-module
>
> > 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
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
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.
BTW - This trend toward faster, lower latency busses is marching
forward. 2 examples; the ioDrive from Fusion IO, Micron's RAM-module
like
Jared Hulbert wrote:
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).
They've already done already better than that. Here's a solid
Alan Cox wrote:
For things like SATA based devices they aren't that fast yet.
You forget the Gigabyte i-RAM.
For others: the i-RAM is a SATA-based device that plugs into a PCI slot
on your motherboard (for power), providing RAM+battery backup as fast as
your SATA bus and DIMMs will go.
On Tue, 04 Dec 2007 15:52:20 -0500
Jeff Garzik [EMAIL PROTECTED] wrote:
Alan Cox wrote:
For things like SATA based devices they aren't that fast yet.
You forget the Gigabyte i-RAM.
For others: the i-RAM is a SATA-based device that plugs into a PCI slot
on your motherboard (for
refinements could theoretically get us down one more (~100
microsecond).
They've already done already better than that. Here's a solid state
drive with a claimed 20 microsecond access time:
http://www.curtisssd.com/products/drives/hyperxclr
Right. That looks to be RAM based, which
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
On Tue, 4 December 2007 13:54:21 -0800, Jared Hulbert wrote:
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?
Doesn't do erase?
Right. The trend is to hide the nastiness of NAND technology changes
behind controllers. In general I think this is a good thing.
You miss the point - any controller you hide it behind almost inevitably
adds enough latency you don't want to use it synchronously.
Alan
--
To unsubscribe from
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?
Doesn't do erase? MTD has to learn almost all tricks from the block
layer,
On Dec 4, 2007 3:24 PM, Alan Cox [EMAIL PROTECTED] wrote:
Right. The trend is to hide the nastiness of NAND technology changes
behind controllers. In general I think this is a good thing.
You miss the point - any controller you hide it behind almost inevitably
adds enough latency you
On Tue, 4 Dec 2007 16:08:07 -0800
Jared Hulbert [EMAIL PROTECTED] wrote:
On Dec 4, 2007 3:24 PM, Alan Cox [EMAIL PROTECTED] wrote:
Right. The trend is to hide the nastiness of NAND technology changes
behind controllers. In general I think this is a good thing.
You miss the point -
Chris Friesen wrote:
Over on comp.os.linux.development.system someone asked an interesting
question, and I thought I'd mention it here.
Given a fast low-latency solid state drive, would it ever be beneficial
to simply wait in the kernel for synchronous read/write calls to
complete? The
> Given a fast low-latency solid state drive, would it ever be beneficial
> to simply wait in the kernel for synchronous read/write calls to
> complete? The idea is that you could avoid at least two task context
> switches, and if the data access can be completed at less cost than
> those
Over on comp.os.linux.development.system someone asked an interesting
question, and I thought I'd mention it here.
Given a fast low-latency solid state drive, would it ever be beneficial
to simply wait in the kernel for synchronous read/write calls to
complete? The idea is that you could
Over on comp.os.linux.development.system someone asked an interesting
question, and I thought I'd mention it here.
Given a fast low-latency solid state drive, would it ever be beneficial
to simply wait in the kernel for synchronous read/write calls to
complete? The idea is that you could
Given a fast low-latency solid state drive, would it ever be beneficial
to simply wait in the kernel for synchronous read/write calls to
complete? The idea is that you could avoid at least two task context
switches, and if the data access can be completed at less cost than
those context
34 matches
Mail list logo
