kvm-devel

Re: [kvm-devel] [patch 2/2] QEMU: decrease console "refresh rate" with -nographic

[Anthony L. <an...@co...>]

Marcelo Tosatti wrote:
> On Tue, Apr 15, 2008 at 05:45:28PM +0300, Avi Kivity wrote:
>   
>> Anthony Liguori wrote:
>>     
>>> Why did we ever need sigtimedwait() anyway?  Even if we were 
>>> select()ing within the VCPU context, we should break out of the 
>>> select() on signal delivery.
>>>
>>>       
>> select() is no good since if the signal is delivered after the select(), 
>> but before entry into guest mode, it is lost.  pselect() might work, but 
>> its is not supported on all hosts, and it (AFAICT) delivers the signals 
>> by calling their handlers, which is slow and unnecessary.
>>     
>
> Anthony tested a patch using signalfd:
>
> http://people.redhat.com/~mtosatti/io-thread-select-timeout
>
> Which is only available on newer hosts. I guess the signals will have to
> stay for older hosts.
>   

With the IO thread, we don't have to worry about lost signals like we do 
in a VCPU thread so it's fine to just use select() and install signal 
handlers IIUC.

Regards,

Anthony Liguori

Re: [kvm-devel] [patch 2/2] QEMU: decrease console "refresh rate" with -nographic

[Avi K. <av...@qu...>]

Anthony Liguori wrote:
>
> With the IO thread, we don't have to worry about lost signals like we 
> do in a VCPU thread so it's fine to just use select() and install 
> signal handlers IIUC.
>

What about aio completions?  The only race-free way to handle both posix 
aio completion and fd readiness is signals AFAIK.

-- 
error compiling committee.c: too many arguments to function

Re: [kvm-devel] [patch 2/2] QEMU: decrease console "refresh rate" with -nographic

[Anthony L. <an...@co...>]

Avi Kivity wrote:
> Anthony Liguori wrote:
>>
>> With the IO thread, we don't have to worry about lost signals like we 
>> do in a VCPU thread so it's fine to just use select() and install 
>> signal handlers IIUC.
>>
>
> What about aio completions?  The only race-free way to handle both 
> posix aio completion and fd readiness is signals AFAIK.

We poll aio completion after the select don't we?  Worst case scenario 
we miss a signal and wait to poll after the next select event.  That's 
going to occur very often because of the timer.

Regards,

Anthony Liguori

Re: [kvm-devel] [patch 2/2] QEMU: decrease console "refresh rate" with -nographic

[Avi K. <av...@qu...>]

Anthony Liguori wrote:
>>
>> What about aio completions?  The only race-free way to handle both 
>> posix aio completion and fd readiness is signals AFAIK.
>
> We poll aio completion after the select don't we?  Worst case scenario 
> we miss a signal and wait to poll after the next select event.  That's 
> going to occur very often because of the timer.

if select() doesn't enable signals (like you can do with pselect) you 
may sit for a long time in select() until the timer expires.

Consider a 100Hz Linux guest running 'ls -lR' out of a cold cache: 
instead of 1-2 ms disk latencies you'll see 10 ms latencies, killing 
performance by a factor of 5.

I see the following possible solutions:

1. Apply Anders' patch and keep I/O completions signal based.

2. Use signalfd() to convert aio completions to fd readiness, emulating 
signalfd() using a thread which does sigwait()+write() (to a pipe) on 
older hosts

3. Use a separate thread for aio completions

4. Use pselect(), live with the race on older hosts (it was introduced 
in 2.6.16, which we barely support anyway), live with the signal 
delivery inefficiency.

When I started writing this email I was in favor of (1), but now with 
the new signalfd emulation I'm leaning towards (2).  I still think (1) 
should be merged, preferably to qemu upstream.

-- 
error compiling committee.c: too many arguments to function

Re: [kvm-devel] [patch 2/2] QEMU: decrease console "refresh rate" with -nographic

[Anders <ma...@fl...>]

Avi Kivity wrote:

> if select() doesn't enable signals (like you can do with pselect) you
> may sit for a long time in select() until the timer expires.

Hm. Does the guest timer affect host userspace in all configurations? The
original trigger for my SIGIO patch was that opening a VNC connection
would take up to a second, until the qemu RTC timer fired.


> Consider a 100Hz Linux guest running 'ls -lR' out of a cold cache:
> instead of 1-2 ms disk latencies you'll see 10 ms latencies, killing
> performance by a factor of 5.

I guess this works out even worse for a dyntick guest?


> I still think (1) should be merged, preferably to qemu upstream.

I will give it another try. They are not very receptive, though, and I am
not that confident in what the patch is actually doing :-). You guys are
helping me a lot in that regard, thanks.


Cheers,
Anders.

Re: [kvm-devel] [patch 2/2] QEMU: decrease console "refresh rate" with -nographic

[Avi K. <av...@qu...>]

Anders wrote:
> Avi Kivity wrote:
>
>   
>> if select() doesn't enable signals (like you can do with pselect) you
>> may sit for a long time in select() until the timer expires.
>>     
>
> Hm. Does the guest timer affect host userspace in all configurations? The
> original trigger for my SIGIO patch was that opening a VNC connection
> would take up to a second, until the qemu RTC timer fired.
>
>   

Right, if the guest is using the lapic or pit timers, there is no 
periodic signal to userspace.

>   
>> Consider a 100Hz Linux guest running 'ls -lR' out of a cold cache:
>> instead of 1-2 ms disk latencies you'll see 10 ms latencies, killing
>> performance by a factor of 5.
>>     
>
> I guess this works out even worse for a dyntick guest?
>
>
>   

Yes.  We can't depend on guest activity for correctness.


-- 
error compiling committee.c: too many arguments to function

Re: [kvm-devel] [patch 2/2] QEMU: decrease console "refresh rate" with -nographic

[Carsten O. <co...@de...>]

Anthony Liguori wrote:
> There is a 5th option.  Do away with the use of posix aio.  We get 
> absolutely no benefit from it because it's limited to a single thread.  
> Fabrice has reverted a patch to change that in the past.
How about using linux aio for it? It seems much better, because it 
doesn't use userspace threads but has a direct in-kernel 
implementation. I've had good performance on zldisk with that, and 
it's stable.

Re: [kvm-devel] [patch 2/2] QEMU: decrease console "refresh rate" with -nographic

[Avi K. <av...@qu...>]

Carsten Otte wrote:
> Anthony Liguori wrote:
>> There is a 5th option.  Do away with the use of posix aio.  We get 
>> absolutely no benefit from it because it's limited to a single 
>> thread.  Fabrice has reverted a patch to change that in the past.
> How about using linux aio for it? It seems much better, because it 
> doesn't use userspace threads but has a direct in-kernel 
> implementation. I've had good performance on zldisk with that, and 
> it's stable.

Linux-aio is nice except that you can't easily complete network and disk 
requests simulateneously (no IO_CMD_POLL yet).  This means you need an 
additional thread.

-- 
error compiling committee.c: too many arguments to function