Stefan Hajnoczi writes:
> On Tue, Apr 1, 2014 at 4:27 AM, Theodore Ts'o wrote:
>> On Mon, Mar 31, 2014 at 02:22:50PM +1030, Rusty Russell wrote:
>>>
>>> It's head of my virtio-next tree.
>>
>> Hey Rusty,
>>
>> While we have your attention --- what's your opinion about adding TRIM
>> support to
Stefan Hajnoczi stefa...@gmail.com writes:
On Tue, Apr 1, 2014 at 4:27 AM, Theodore Ts'o ty...@mit.edu wrote:
On Mon, Mar 31, 2014 at 02:22:50PM +1030, Rusty Russell wrote:
It's head of my virtio-next tree.
Hey Rusty,
While we have your attention --- what's your opinion about adding TRIM
On Tue, Apr 1, 2014 at 4:27 AM, Theodore Ts'o wrote:
> On Mon, Mar 31, 2014 at 02:22:50PM +1030, Rusty Russell wrote:
>>
>> It's head of my virtio-next tree.
>
> Hey Rusty,
>
> While we have your attention --- what's your opinion about adding TRIM
> support to virtio-blk. I understand that
On Tue, Apr 1, 2014 at 4:27 AM, Theodore Ts'o ty...@mit.edu wrote:
On Mon, Mar 31, 2014 at 02:22:50PM +1030, Rusty Russell wrote:
It's head of my virtio-next tree.
Hey Rusty,
While we have your attention --- what's your opinion about adding TRIM
support to virtio-blk. I understand that
On Mon, Mar 31, 2014 at 02:22:50PM +1030, Rusty Russell wrote:
>
> It's head of my virtio-next tree.
Hey Rusty,
While we have your attention --- what's your opinion about adding TRIM
support to virtio-blk. I understand that you're starting an OASIS
standardization process for virtio --- what
On Mon, Mar 31, 2014 at 02:22:50PM +1030, Rusty Russell wrote:
It's head of my virtio-next tree.
Hey Rusty,
While we have your attention --- what's your opinion about adding TRIM
support to virtio-blk. I understand that you're starting an OASIS
standardization process for virtio --- what
Venkatesh Srinivas writes:
> On Wed, Mar 19, 2014 at 10:48 AM, Venkatesh Srinivas
> wrote:
>>> And I rewrote it substantially, mainly to take
>>> VIRTIO_RING_F_INDIRECT_DESC into account.
>>>
>>> As QEMU sets the vq size for PCI to 128, Venkatash's patch wouldn't
>>> have made a change. This
Venkatesh Srinivas venkate...@google.com writes:
On Wed, Mar 19, 2014 at 10:48 AM, Venkatesh Srinivas
venkate...@google.com wrote:
And I rewrote it substantially, mainly to take
VIRTIO_RING_F_INDIRECT_DESC into account.
As QEMU sets the vq size for PCI to 128, Venkatash's patch wouldn't
On Wed, Mar 19, 2014 at 10:48 AM, Venkatesh Srinivas
wrote:
>> And I rewrote it substantially, mainly to take
>> VIRTIO_RING_F_INDIRECT_DESC into account.
>>
>> As QEMU sets the vq size for PCI to 128, Venkatash's patch wouldn't
>> have made a change. This version does (since QEMU also offers
>>
On Wed, Mar 19, 2014 at 10:48 AM, Venkatesh Srinivas
venkate...@google.com wrote:
And I rewrote it substantially, mainly to take
VIRTIO_RING_F_INDIRECT_DESC into account.
As QEMU sets the vq size for PCI to 128, Venkatash's patch wouldn't
have made a change. This version does (since QEMU
> And I rewrote it substantially, mainly to take
> VIRTIO_RING_F_INDIRECT_DESC into account.
>
> As QEMU sets the vq size for PCI to 128, Venkatash's patch wouldn't
> have made a change. This version does (since QEMU also offers
> VIRTIO_RING_F_INDIRECT_DESC.
That divide-by-2 produced the same
ty...@mit.edu writes:
> On Mon, Mar 17, 2014 at 11:12:15AM +1030, Rusty Russell wrote:
>>
>> Note that with indirect descriptors (which is supported by Almost
>> Everyone), we can actually use the full index, so this value is a bit
>> pessimistic. But it's OK as a starting point.
>
> So is this
ty...@mit.edu writes:
On Mon, Mar 17, 2014 at 11:12:15AM +1030, Rusty Russell wrote:
Note that with indirect descriptors (which is supported by Almost
Everyone), we can actually use the full index, so this value is a bit
pessimistic. But it's OK as a starting point.
So is this something
And I rewrote it substantially, mainly to take
VIRTIO_RING_F_INDIRECT_DESC into account.
As QEMU sets the vq size for PCI to 128, Venkatash's patch wouldn't
have made a change. This version does (since QEMU also offers
VIRTIO_RING_F_INDIRECT_DESC.
That divide-by-2 produced the same queue
On Mon, Mar 17, 2014 at 11:12:15AM +1030, Rusty Russell wrote:
>
> Note that with indirect descriptors (which is supported by Almost
> Everyone), we can actually use the full index, so this value is a bit
> pessimistic. But it's OK as a starting point.
So is this something that can go upstream
Theodore Ts'o writes:
> The current virtio block sets a queue depth of 64, which is
> insufficient for very fast devices. It has been demonstrated that
> with a high IOPS device, using a queue depth of 256 can double the
> IOPS which can be sustained.
>
> As suggested by Venkatash Srinivas, set
Theodore Ts'o ty...@mit.edu writes:
The current virtio block sets a queue depth of 64, which is
insufficient for very fast devices. It has been demonstrated that
with a high IOPS device, using a queue depth of 256 can double the
IOPS which can be sustained.
As suggested by Venkatash
On Mon, Mar 17, 2014 at 11:12:15AM +1030, Rusty Russell wrote:
Note that with indirect descriptors (which is supported by Almost
Everyone), we can actually use the full index, so this value is a bit
pessimistic. But it's OK as a starting point.
So is this something that can go upstream with
On Sat, Mar 15, 2014 at 06:57:23AM -0700, Christoph Hellwig wrote:
> I don't think this should be a module parameter. The default sizing
> should be based of the parameters of the actual virtqueue, and if we
> want to allow tuning it it should be by a sysfs attribute, preferable
> using the same
On Fri, Mar 14, 2014 at 11:34:31PM -0400, Theodore Ts'o wrote:
> The current virtio block sets a queue depth of 64, which is
> insufficient for very fast devices. It has been demonstrated that
> with a high IOPS device, using a queue depth of 256 can double the
> IOPS which can be sustained.
>
>
On Sat, Mar 15, 2014 at 06:57:01AM -0400, Konrad Rzeszutek Wilk wrote:
> >+pr_info("%s: using queue depth %d\n", vblk->disk->disk_name,
> >+virtio_mq_reg.queue_depth);
>
> Isn't that visible from sysfs?
As near as I can tell, it's not. I haven't been able to find anything
that
On March 14, 2014 11:34:31 PM EDT, Theodore Ts'o wrote:
>The current virtio block sets a queue depth of 64, which is
>insufficient for very fast devices. It has been demonstrated that
>with a high IOPS device, using a queue depth of 256 can double the
>IOPS which can be sustained.
>
>As
On March 14, 2014 11:34:31 PM EDT, Theodore Ts'o ty...@mit.edu wrote:
The current virtio block sets a queue depth of 64, which is
insufficient for very fast devices. It has been demonstrated that
with a high IOPS device, using a queue depth of 256 can double the
IOPS which can be sustained.
As
On Sat, Mar 15, 2014 at 06:57:01AM -0400, Konrad Rzeszutek Wilk wrote:
+pr_info(%s: using queue depth %d\n, vblk-disk-disk_name,
+virtio_mq_reg.queue_depth);
Isn't that visible from sysfs?
As near as I can tell, it's not. I haven't been able to find anything
that either
On Fri, Mar 14, 2014 at 11:34:31PM -0400, Theodore Ts'o wrote:
The current virtio block sets a queue depth of 64, which is
insufficient for very fast devices. It has been demonstrated that
with a high IOPS device, using a queue depth of 256 can double the
IOPS which can be sustained.
As
On Sat, Mar 15, 2014 at 06:57:23AM -0700, Christoph Hellwig wrote:
I don't think this should be a module parameter. The default sizing
should be based of the parameters of the actual virtqueue, and if we
want to allow tuning it it should be by a sysfs attribute, preferable
using the same
The current virtio block sets a queue depth of 64, which is
insufficient for very fast devices. It has been demonstrated that
with a high IOPS device, using a queue depth of 256 can double the
IOPS which can be sustained.
As suggested by Venkatash Srinivas, set the queue depth by default to
be
The current virtio block sets a queue depth of 64, which is
insufficient for very fast devices. It has been demonstrated that
with a high IOPS device, using a queue depth of 256 can double the
IOPS which can be sustained.
As suggested by Venkatash Srinivas, set the queue depth by default to
be
28 matches
Mail list logo
