* [Qemu-devel] Windows and I/O size
@ 2013-01-08 8:16 Peter Lieven
2013-01-08 8:50 ` Vadim Rozenfeld
0 siblings, 1 reply; 8+ messages in thread
From: Peter Lieven @ 2013-01-08 8:16 UTC (permalink / raw)
To: qemu-devel@nongnu.org; +Cc: Vadim Rozenfeld, ronnie sahlberg
Hi all,
I came across the fact that Windows seems to requests greater 64KB into pieces leading to a lot of IOPs on the storage
side.
Can anyone imagine of a way to merge them before sending them to e.g. an iSCSI Storage? 64KB I/O Size is not optimal
when e.g. large sequential operations with an iSCSI target.
Thank you,
Peter
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Qemu-devel] Windows and I/O size
2013-01-08 8:16 [Qemu-devel] Windows and I/O size Peter Lieven
@ 2013-01-08 8:50 ` Vadim Rozenfeld
2013-01-08 8:53 ` Peter Lieven
0 siblings, 1 reply; 8+ messages in thread
From: Vadim Rozenfeld @ 2013-01-08 8:50 UTC (permalink / raw)
To: Peter Lieven; +Cc: qemu-devel@nongnu.org, ronnie sahlberg
On Tuesday, January 08, 2013 10:16:48 AM Peter Lieven wrote:
> Hi all,
>
> I came across the fact that Windows seems to requests greater 64KB into
> pieces leading to a lot of IOPs on the storage side.
>
> Can anyone imagine of a way to merge them before sending them to e.g. an
> iSCSI Storage? 64KB I/O Size is not optimal when e.g. large sequential
> operations with an iSCSI target.
>
> Thank you,
> Peter
Hi Peter.
Is it viostor? Which version? The most recent one is able to handle 256K
blocks.
Best regards,
Vadim.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Qemu-devel] Windows and I/O size
2013-01-08 8:50 ` Vadim Rozenfeld
@ 2013-01-08 8:53 ` Peter Lieven
2013-01-08 9:29 ` Vadim Rozenfeld
0 siblings, 1 reply; 8+ messages in thread
From: Peter Lieven @ 2013-01-08 8:53 UTC (permalink / raw)
To: Vadim Rozenfeld; +Cc: qemu-devel@nongnu.org, ronnie sahlberg
Am 08.01.2013 um 09:50 schrieb Vadim Rozenfeld <vrozenfe@redhat.com>:
> On Tuesday, January 08, 2013 10:16:48 AM Peter Lieven wrote:
>> Hi all,
>>
>> I came across the fact that Windows seems to requests greater 64KB into
>> pieces leading to a lot of IOPs on the storage side.
>>
>> Can anyone imagine of a way to merge them before sending them to e.g. an
>> iSCSI Storage? 64KB I/O Size is not optimal when e.g. large sequential
>> operations with an iSCSI target.
>>
>> Thank you,
>> Peter
> Hi Peter.
> Is it viostor? Which version? The most recent one is able to handle 256K
> blocks.
Not the recent. I will try 0.1.49 now.
256KB is still not that much but definitely better than 64KB. are this windows limits?
I have found docs in the net that windows splits up everything into 64kB requests. Is this
info old?
thank you,
Peter
>
> Best regards,
> Vadim.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Qemu-devel] Windows and I/O size
2013-01-08 8:53 ` Peter Lieven
@ 2013-01-08 9:29 ` Vadim Rozenfeld
2013-01-08 9:47 ` Peter Lieven
2013-01-08 10:09 ` Peter Lieven
0 siblings, 2 replies; 8+ messages in thread
From: Vadim Rozenfeld @ 2013-01-08 9:29 UTC (permalink / raw)
To: Peter Lieven; +Cc: qemu-devel@nongnu.org, ronnie sahlberg
On Tuesday, January 08, 2013 10:53:44 AM Peter Lieven wrote:
> Am 08.01.2013 um 09:50 schrieb Vadim Rozenfeld <vrozenfe@redhat.com>:
> > On Tuesday, January 08, 2013 10:16:48 AM Peter Lieven wrote:
> >> Hi all,
> >>
> >> I came across the fact that Windows seems to requests greater 64KB into
> >> pieces leading to a lot of IOPs on the storage side.
> >>
> >> Can anyone imagine of a way to merge them before sending them to e.g. an
> >> iSCSI Storage? 64KB I/O Size is not optimal when e.g. large sequential
> >> operations with an iSCSI target.
> >>
> >> Thank you,
> >> Peter
> >
> > Hi Peter.
> > Is it viostor? Which version? The most recent one is able to handle 256K
> > blocks.
>
> Not the recent. I will try 0.1.49 now.
>
> 256KB is still not that much but definitely better than 64KB. are this
> windows limits?
not exactly. it came from the driver itself. actually, with indirect buffer
support in virtio the sky is the limit.
>
> I have found docs in the net that windows splits up everything into 64kB
> requests. Is this info old?
>
> thank you,
> Peter
>
> > Best regards,
> > Vadim.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Qemu-devel] Windows and I/O size
2013-01-08 9:29 ` Vadim Rozenfeld
@ 2013-01-08 9:47 ` Peter Lieven
2013-01-08 10:15 ` Vadim Rozenfeld
2013-01-08 10:09 ` Peter Lieven
1 sibling, 1 reply; 8+ messages in thread
From: Peter Lieven @ 2013-01-08 9:47 UTC (permalink / raw)
To: Vadim Rozenfeld; +Cc: qemu-devel@nongnu.org, ronnie sahlberg
Am 08.01.2013 um 10:29 schrieb Vadim Rozenfeld <vrozenfe@redhat.com>:
> On Tuesday, January 08, 2013 10:53:44 AM Peter Lieven wrote:
>> Am 08.01.2013 um 09:50 schrieb Vadim Rozenfeld <vrozenfe@redhat.com>:
>>> On Tuesday, January 08, 2013 10:16:48 AM Peter Lieven wrote:
>>>> Hi all,
>>>>
>>>> I came across the fact that Windows seems to requests greater 64KB into
>>>> pieces leading to a lot of IOPs on the storage side.
>>>>
>>>> Can anyone imagine of a way to merge them before sending them to e.g. an
>>>> iSCSI Storage? 64KB I/O Size is not optimal when e.g. large sequential
>>>> operations with an iSCSI target.
>>>>
>>>> Thank you,
>>>> Peter
>>>
>>> Hi Peter.
>>> Is it viostor? Which version? The most recent one is able to handle 256K
>>> blocks.
>>
>> Not the recent. I will try 0.1.49 now.
>>
>> 256KB is still not that much but definitely better than 64KB. are this
>> windows limits?
>
> not exactly. it came from the driver itself. actually, with indirect buffer
> support in virtio the sky is the limit.
would it be possible to make this value user adjustable in the driver settings?
I can meanwhile confirm that the IOPS for sequential reads (writes not tested)
have dropped to 1/4 as expected.
I think 256K is a reasonable value. What was the reason to choose it?
Thank you,
Peter
>
>>
>> I have found docs in the net that windows splits up everything into 64kB
>> requests. Is this info old?
>>
>> thank you,
>> Peter
>>
>>> Best regards,
>>> Vadim.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Qemu-devel] Windows and I/O size
2013-01-08 9:47 ` Peter Lieven
@ 2013-01-08 10:15 ` Vadim Rozenfeld
0 siblings, 0 replies; 8+ messages in thread
From: Vadim Rozenfeld @ 2013-01-08 10:15 UTC (permalink / raw)
To: Peter Lieven; +Cc: qemu-devel@nongnu.org, ronnie sahlberg
On Tuesday, January 08, 2013 11:47:54 AM Peter Lieven wrote:
> Am 08.01.2013 um 10:29 schrieb Vadim Rozenfeld <vrozenfe@redhat.com>:
> > On Tuesday, January 08, 2013 10:53:44 AM Peter Lieven wrote:
> >> Am 08.01.2013 um 09:50 schrieb Vadim Rozenfeld <vrozenfe@redhat.com>:
> >>> On Tuesday, January 08, 2013 10:16:48 AM Peter Lieven wrote:
> >>>> Hi all,
> >>>>
> >>>> I came across the fact that Windows seems to requests greater 64KB
> >>>> into pieces leading to a lot of IOPs on the storage side.
> >>>>
> >>>> Can anyone imagine of a way to merge them before sending them to e.g.
> >>>> an iSCSI Storage? 64KB I/O Size is not optimal when e.g. large
> >>>> sequential operations with an iSCSI target.
> >>>>
> >>>> Thank you,
> >>>> Peter
> >>>
> >>> Hi Peter.
> >>> Is it viostor? Which version? The most recent one is able to handle
> >>> 256K blocks.
> >>
> >> Not the recent. I will try 0.1.49 now.
> >>
> >> 256KB is still not that much but definitely better than 64KB. are this
> >> windows limits?
> >
> > not exactly. it came from the driver itself. actually, with indirect
> > buffer support in virtio the sky is the limit.
>
> would it be possible to make this value user adjustable in the driver
> settings?
>
technically, yes.
> I can meanwhile confirm that the IOPS for sequential reads (writes not
> tested) have dropped to 1/4 as expected.
>
> I think 256K is a reasonable value. What was the reason to choose it?
In Windows cache manager operates with 256 KB blocks.
Cheers,
Vadim.
>
> Thank you,
> Peter
>
> >> I have found docs in the net that windows splits up everything into 64kB
> >> requests. Is this info old?
> >>
> >> thank you,
> >> Peter
> >>
> >>> Best regards,
> >>> Vadim.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Qemu-devel] Windows and I/O size
2013-01-08 9:29 ` Vadim Rozenfeld
2013-01-08 9:47 ` Peter Lieven
@ 2013-01-08 10:09 ` Peter Lieven
2013-01-08 10:21 ` Vadim Rozenfeld
1 sibling, 1 reply; 8+ messages in thread
From: Peter Lieven @ 2013-01-08 10:09 UTC (permalink / raw)
To: Vadim Rozenfeld; +Cc: qemu-devel@nongnu.org, ronnie sahlberg
Am 08.01.2013 um 10:29 schrieb Vadim Rozenfeld <vrozenfe@redhat.com>:
> On Tuesday, January 08, 2013 10:53:44 AM Peter Lieven wrote:
>> Am 08.01.2013 um 09:50 schrieb Vadim Rozenfeld <vrozenfe@redhat.com>:
>>> On Tuesday, January 08, 2013 10:16:48 AM Peter Lieven wrote:
>>>> Hi all,
>>>>
>>>> I came across the fact that Windows seems to requests greater 64KB into
>>>> pieces leading to a lot of IOPs on the storage side.
>>>>
>>>> Can anyone imagine of a way to merge them before sending them to e.g. an
>>>> iSCSI Storage? 64KB I/O Size is not optimal when e.g. large sequential
>>>> operations with an iSCSI target.
>>>>
>>>> Thank you,
>>>> Peter
>>>
>>> Hi Peter.
>>> Is it viostor? Which version? The most recent one is able to handle 256K
>>> blocks.
>>
>> Not the recent. I will try 0.1.49 now.
>>
>> 256KB is still not that much but definitely better than 64KB. are this
>> windows limits?
>
> not exactly. it came from the driver itself. actually, with indirect buffer
> support in virtio the sky is the limit.
is indirect buffering supported on all windows platforms?
Peter
>
>>
>> I have found docs in the net that windows splits up everything into 64kB
>> requests. Is this info old?
>>
>> thank you,
>> Peter
>>
>>> Best regards,
>>> Vadim.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Qemu-devel] Windows and I/O size
2013-01-08 10:09 ` Peter Lieven
@ 2013-01-08 10:21 ` Vadim Rozenfeld
0 siblings, 0 replies; 8+ messages in thread
From: Vadim Rozenfeld @ 2013-01-08 10:21 UTC (permalink / raw)
To: Peter Lieven; +Cc: qemu-devel@nongnu.org, ronnie sahlberg
On Tuesday, January 08, 2013 12:09:11 PM Peter Lieven wrote:
> Am 08.01.2013 um 10:29 schrieb Vadim Rozenfeld <vrozenfe@redhat.com>:
> > On Tuesday, January 08, 2013 10:53:44 AM Peter Lieven wrote:
> >> Am 08.01.2013 um 09:50 schrieb Vadim Rozenfeld <vrozenfe@redhat.com>:
> >>> On Tuesday, January 08, 2013 10:16:48 AM Peter Lieven wrote:
> >>>> Hi all,
> >>>>
> >>>> I came across the fact that Windows seems to requests greater 64KB
> >>>> into pieces leading to a lot of IOPs on the storage side.
> >>>>
> >>>> Can anyone imagine of a way to merge them before sending them to e.g.
> >>>> an iSCSI Storage? 64KB I/O Size is not optimal when e.g. large
> >>>> sequential operations with an iSCSI target.
> >>>>
> >>>> Thank you,
> >>>> Peter
> >>>
> >>> Hi Peter.
> >>> Is it viostor? Which version? The most recent one is able to handle
> >>> 256K blocks.
> >>
> >> Not the recent. I will try 0.1.49 now.
> >>
> >> 256KB is still not that much but definitely better than 64KB. are this
> >> windows limits?
> >
> > not exactly. it came from the driver itself. actually, with indirect
> > buffer support in virtio the sky is the limit.
>
> is indirect buffering supported on all windows platforms?
yes.
btw, forgot to mention that vioscsi doesn't have this feature yet.
>
> Peter
>
> >> I have found docs in the net that windows splits up everything into 64kB
> >> requests. Is this info old?
> >>
> >> thank you,
> >> Peter
> >>
> >>> Best regards,
> >>> Vadim.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2013-01-08 10:21 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-01-08 8:16 [Qemu-devel] Windows and I/O size Peter Lieven
2013-01-08 8:50 ` Vadim Rozenfeld
2013-01-08 8:53 ` Peter Lieven
2013-01-08 9:29 ` Vadim Rozenfeld
2013-01-08 9:47 ` Peter Lieven
2013-01-08 10:15 ` Vadim Rozenfeld
2013-01-08 10:09 ` Peter Lieven
2013-01-08 10:21 ` Vadim Rozenfeld
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).