On 05/16/2014 09:00 AM, Stefan Weil wrote:
> Am 09.05.2014 20:57, schrieb Stefan Hajnoczi:
>> On Thu, May 08, 2014 at 12:47:10PM +0400, Stanislav Vorobiov wrote:
>>> From: Sangho Park
>>>
>>> g_poll has a problem on Windows when using
>>> timeouts &l
is called with timeout < 10ms it does
a quick poll instead of wait, this causes significant performance
degradation of QEMU, thus we should use WaitForMultipleObjectsEx
directly
Signed-off-by: Stanislav Vorobiov
---
include/glib-compat.h |9 +++-
util/oslib-
Hi,
IMHO it's not a problem, automerge will resolve this
On 05/07/2014 04:21 PM, Michael Tokarev wrote:
> 07.05.2014 13:07, Stanislav Vorobiov wrote:
>> From: Sangho Park
> []
>> include/glib-compat.h | 19 +
>> include/qemu-common.h | 12 --
>
&
is called with timeout < 10ms it does
a quick poll instead of wait, this causes significant performance
degradation of QEMU, thus we should use WaitForMultipleObjectsEx
directly
Signed-off-by: Stanislav Vorobiov
---
include/glib-compat.h | 19 +
include/qemu-common.h | 12 --
u
Hi,
Yes it's probably the cause, thanks.
On 05/07/2014 12:49 PM, Alex Bligh wrote:
>
> On 7 May 2014, at 09:36, Stanislav Vorobiov wrote:
>
>> Hi,
>>
>> Hm, but (int)res expression is not unsigned, it's signed. I've also had this
>> warning,
&
ld be
really strange though...
On 05/07/2014 12:02 PM, Stefan Hajnoczi wrote:
> On Fri, Apr 18, 2014 at 08:24:03PM +0400, Stanislav Vorobiov wrote:
>
> Please fix the following compiler warning with gcc 4.8.2:
>
>> +} else if ((res == WAIT_TIMEOUT) || (res ==
linux kernel 3.12 has changed intel-hda
driver to always check for FIFORDY, this
causes long hangs in guest since QEMU
always has this bit set to 0. We now simply set
it to 1 always, since we're synchronous anyway
and always ready to receive the stream
Signed-off-by: Stanislav Vorobiov
--
clude something like supporting SSYNC flag as
well, pausing the stream when it's 0 and resuming
when it's 1, if someone is willing to implement
this then great, but with this patch at least the guest
doesn't hang
Stanislav Vorobiov (1):
audio/intel-hda: support FIFORDY
hw/audio/intel
Hi, see below
On 04/22/2014 01:21 PM, Alex Bligh wrote:
>
> On 22 Apr 2014, at 10:03, Stanislav Vorobiov wrote:
>
>>> + */
>>> +#define g_poll(fds, nfds, timeout) g_poll_fixed(fds, nfds, timeout)
>>> +gint g_poll_fixed(GPollFD *fds, guint nfds, gint timeout);
Hi everyone,
Any comments on this v3 patch ?
On 04/18/2014 08:24 PM, Stanislav Vorobiov wrote:
> From: Sangho Park
>
> g_poll has a problem on Windows when using
> timeouts < 10ms, in glib/gpoll.c:
>
> /* If not, and we have a significant timeout, poll again with
> *
is called with timeout < 10ms it does
a quick poll instead of wait, this causes significant performance
degradation of QEMU, thus we should use WaitForMultipleObjectsEx
directly
Signed-off-by: Stanislav Vorobiov
---
include/glib-compat.h | 19 +
include/qemu-common.h | 12 --
u
is called with timeout < 10ms it does
a quick poll instead of wait, this causes significant performance
degradation of qemu, thus we should use WaitForMultipleObjectsEx
directly
Signed-off-by: Stanislav Vorobiov
---
include/glib-compat.h | 19 +
include/qemu-common.h | 12 --
u
Hi, see below
On 04/18/2014 12:03 PM, Stefan Weil wrote:
> Am 18.04.2014 09:34, schrieb Stanislav Vorobiov:
>> Hi,
>>
>> Please see below
>>
>> On 04/18/2014 10:46 AM, Stefan Weil wrote:
>>> Hi,
> [...]
>>
>>>
>>> Would it
Hi,
Please see below
On 04/18/2014 12:29 PM, Alex Bligh wrote:
>
> On 18 Apr 2014, at 03:11, Sangho Park wrote:
>
>>>
>>> g_poll has a problem on windows when using timeouts < 10ms, in
>>> glib/gpoll.c:
>>>
>>> /* If not, and we have a significant timeout, poll again with
>>> * timeout then. N
g/msg227161.html
>>
>> Thanks
>>
>> ps)
>> We've checked the http://wiki.qemu.org/Contribute/SubmitAPatch. Yet, if we
>> made any violation or mistake, let us know. We will appreciate your favor.
>>
>> -Original Message-
>> From: Stanislav Voro
Hi, everyone
Any comments on this one ? This patch fixes
pretty serious performance issues on windows, it would be
great to have this in 2.0.0
On 04/15/2014 12:41 PM, Stanislav Vorobiov wrote:
> From: Sangho Park
>
> g_poll has a problem on windows when using
> timeouts < 10ms,
is called with timeout < 10ms it does
a quick poll instead of wait, this causes significant performance
degradation of qemu, thus we should use WaitForMultipleObjectsEx
directly
Signed-off-by: Stanislav Vorobiov
---
qemu-timer.c | 91 +
17 matches
Mail list logo
