Re: [Qemu-devel] Main loop

[Anthony Liguori]

malc wrote:
> On Sat, 26 Sep 2009, Anthony Liguori wrote:
>
>   
> > malc wrote:
> >     
> > > At http://repo.or.cz/w/qemu/malc.git?a=shortlog;h=refs/heads/mtloop you
> > > can find the branch which refactors main execution loop somewhat, effects
> > > include:
> > >
> > > a. Host alarm timers are gone
> > > b. IO thread is replaced (now Windows is supported too)
> > >   
> > >       
> > What was the motivation?
> >     
>
> To have working audio on my 250 Hz system, where audio polling mode
> ensures that wakeups happen at ~1Khz (with sufficiently small fragment
> size) thus allowing Fast Tracker 2 to run properly. IOW this approach
> allows to react to FD activity indpendantly of any timers.
>   

Ah, yes.  This is also addressed by the IO thread FWIW.  The IO thread 
can run select without holding a mutex and can send a signal to the TCG 
thread in order to break it's execution out before attempting to acquire 
the global mutex.

> Things i forgot to mention, slirp crawls (i.e. when sending some file
> with nc to the guest the (hidden[1]) cpu utilization is only at ~50%
> and subsequently it takes (relative to alarm mode) forever for transfer
> to finnish, FWIW same problem plagues IO Thread)
>   

The slirp issue is that it has a hook in the polling loop.  The IO 
thread doesn't suffer from this problem because slirp is driven in the 
IO thread itself which still receives regular signals.

FWIW, I consider the fact that slirp (or anything else) requires 
periodic polling to be a bug.

> This is the 5 or 6th internal iteration of the thing, at one point i had
> a system working where tcg only held the locks during the IO/helpers, but
> in the end complexity wasn't worth it.
>   

Glauber spent some time with the IO thread recently.  Any reason you 
didn't start with the existing IO thread (besides the fact that it 
doesn't work with TCG)?

Regards,

Anthony Liguori