Re: [Qemu-devel] Re: [PATCH 2/7] Enable I/O thread and VNC threads by default

[Anthony Liguori]

On 02/08/2011 05:46 AM, Aurelien Jarno wrote:
> On Tue, Feb 08, 2011 at 12:07:02PM +0100, Tristan Gingold wrote:
>    
> > On Feb 8, 2011, at 6:58 PM, Anthony Liguori wrote:
> >
> >      
> > > On 02/08/2011 04:06 AM, Aurelien Jarno wrote:
> > >        
> > > > Yes, it's slow. But is it a problem? You assume that people use QEMU
> > > > only for emulating SMP platforms. This is a wrong assumption. Beside the
> > > > x86 target, only sparc really supports SMP emulation.
> > > >
> > > >          
> > > It's *not* just about performance.
> > >
> > > TCG requires a signal to break out of a tight chained TB loop.  If you have a 
> > > guest in a tight loop waiting for something external (like polling on a 
> > > in-memory flag), the device emulation will not get to run until a signal is 
> > > fired.
> > >
> > > Unless you set SIGIO on every file descriptor that selects polls on (and you 
> > > can't because there are a number that just don't support SIGIO), then you have 
> > > a race condition.
> > >        
> > A race condition ?  Looks like you are describing a dead-lock.
> >
> > But the dead lock doesn't happen because of the timer which periodically exits 
> > from TCG.  Hence the performance issue.
> >      

With dynticks, you don't always have a periodic timer (unless the guest 
has a periodic timer enabled).  There's a good bit of early startup code 
that runs without a periodic timer enabled.

Now that said, we never truly sleep forever.  We'll set something like a 
5 second timeout.  But 5 seconds might as well be forever and this is 
certainly a giant hack.

Regards,

Anthony Liguori

> > > This can be fixed by running TCG in a separate thread than select() and sending 
> > > a signal to the TCG VCPU when select() returns (effectively SIGIO in userspace).
> > >
> > > This is exactly what the I/O thread does.
> > >        
> >
> > (Nobody was able to make it working on Windows - or nobody was interested in ?)
> >
> >      
> Given the I/O thread is disabled by default, my guess is that nobody
> really see an interest in looking at that.
>
>