i...@bsdimp.com (Warner Losh) writes:
>I've not used any m.2 devices. These tests were raw dd's of 128k I/Os
>with one thread of execution, so no effective queueing at all.
gossam: {4} dd if=/dev/rdk0 bs=128k of=/dev/null count=10
10+0 records in
10+0 records out
1310720 bytes
On Mon, Sep 26, 2016 at 8:27 AM, Michael van Elst wrote:
> i...@bsdimp.com (Warner Losh) writes:
>
>>NVMe is even worse. There's one drive that w/o queueing I can barely
>>get 1GB/s out of. With queueing and multiple requests I can get the
>>spec sheet rated 3.6GB/s. Here
b...@softjar.se (Johnny Billquist) writes:
>Good point. In which case (if I read you right), it's not the reordering
>that matters, but the simple case of being able to queue up several
>operations, to keep the disk busy.
For sequential reading we are currently limited to 8 operations in
i...@bsdimp.com (Warner Losh) writes:
>NVMe is even worse. There's one drive that w/o queueing I can barely
>get 1GB/s out of. With queueing and multiple requests I can get the
>spec sheet rated 3.6GB/s. Here queueing is critical for Netflix to get to
>90-93Gbps that our 100Gbps boxes can do
On Fri, Sep 23, 2016 at 01:02:26PM +, paul.kon...@dell.com wrote:
>
> > On Sep 23, 2016, at 5:49 AM, Edgar Fu?? wrote:
> >
> >> The whole point of tagged queueing is to let you *not* set [the write
> >> cache] bit in the mode pages and still get good performance.
> >
> On Sep 23, 2016, at 5:49 AM, Edgar Fuß wrote:
>
>> The whole point of tagged queueing is to let you *not* set [the write
>> cache] bit in the mode pages and still get good performance.
> I don't get that. My understanding was that TCQ allowed the drive to re-order
>
On Fri, Sep 23, 2016 at 8:05 AM, Thor Lancelot Simon wrote:
> Our storage stack's inability to use tags with SATA targets is a huge
> gating factor for performance with real workloads (the residual use of
> the kernel lock at and below the bufq layer is another).
FreeBSD's
On Fri, Sep 23, 2016 at 09:38:08AM -0400, Greg Troxel wrote:
>
> Johnny Billquist writes:
>
> > With rotating rust, the order of operations can make a huge difference
> > in speed. With SSDs you don't have those seek times to begin with, so
> > I would expect the gains to be
On 2016-09-23 15:38, Greg Troxel wrote:
Johnny Billquist writes:
With rotating rust, the order of operations can make a huge difference
in speed. With SSDs you don't have those seek times to begin with, so
I would expect the gains to be marginal.
For reordering, I agree
Johnny Billquist writes:
> With rotating rust, the order of operations can make a huge difference
> in speed. With SSDs you don't have those seek times to begin with, so
> I would expect the gains to be marginal.
For reordering, I agree with you, but the SSD speeds are so high
On 2016-09-23 13:05, David Holland wrote:
On Fri, Sep 23, 2016 at 11:49:50AM +0200, Edgar Fu? wrote:
> > The whole point of tagged queueing is to let you *not* set [the write
> > cache] bit in the mode pages and still get good performance.
>
> I don't get that. My understanding was that TCQ
On Fri, Sep 23, 2016 at 01:13:09PM +0200, Edgar Fuß wrote:
> > You can have more than one in flight at a time.
> My SCSI knowledge is probably out-dated. How can I have several commands
> in flight concurrently?
This is what tagged queueing is for.
--
Manuel Bouyer
> You can have more than one in flight at a time.
My SCSI knowledge is probably out-dated. How can I have several commands
in flight concurrently?
On 2016-09-23 11:49, Edgar Fuß wrote:
The whole point of tagged queueing is to let you *not* set [the write
cache] bit in the mode pages and still get good performance.
I don't get that. My understanding was that TCQ allowed the drive to re-order
commands within the bounds described by the
On Fri, Sep 23, 2016 at 11:49:50AM +0200, Edgar Fu? wrote:
> > The whole point of tagged queueing is to let you *not* set [the write
> > cache] bit in the mode pages and still get good performance.
>
> I don't get that. My understanding was that TCQ allowed the drive
> to re-order commands
> The whole point of tagged queueing is to let you *not* set [the write
> cache] bit in the mode pages and still get good performance.
I don't get that. My understanding was that TCQ allowed the drive to re-order
commands within the bounds described by the tags. With the write cache
disabled,
16 matches
Mail list logo