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 vi
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 you're
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 do
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 ver
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
>>
> 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 qu
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 s
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 w
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 t
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 s
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 ei
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 suggested
13 matches
Mail list logo
