Re: [Qemu-devel] Main loop

[malc]

On Sun, 27 Sep 2009, Anthony Liguori wrote:

> 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.

Huh? I said the same issue _applies_ to IO Thread, you are contradicting
it, how come?

> 
> > 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)?
> 

Because i wasn't writing a replacement for IO Thread to begin with (btw it
does work with TCG), what it doesn't do is play nicely with icount[1], 
work on Windows, and for mysterious reasons still requires alarm timers, 
it also deadlocks for me when killing QEMU windows while running smp 
guest, but that's easily corrected mistake somewhere i guess.

[1] Current mtloop has an issue with icount also, halt related.

-- 
mailto:address@hidden