On Thu, Mar 27, 2008 at 05:23:38PM +0200, Avi Kivity wrote: > Marcelo Tosatti wrote: > >Move IO processing from vcpu0 to a dedicated thread. > > > >This removes load on vcpu0 by allowing better cache locality and also > >improves latency. > > > > > > Does live migration (and stop/cont) still work with this?
Yes, live migration works with UP. SMP migration is broken, but its not an issue related to pausing/resuming of threads (its broken even without the change). What happens is that all threads run successfully on the target (you can see the guest reading the PM timer), but its locked wasting lots of CPU cycles (KVM is emulating some instruction(s)). Will look into it later. > > >We can now block signal handling for IO events, so sigtimedwait won't > >race with handlers: > > > >- Currently the SIGALRM handler fails to set CPU_INTERRUPT_EXIT because > >the "next_cpu" variable is not initialized in the KVM path, meaning that > >processing of timer expiration might be delayed until the next vcpu0 exit. > > > > I still don't understand this. Timer expiration ought to be processed > in the iothread, when SIGALRM is dequeued, and be completely unrelated > to whatever vcpu 0 is doing. Yes, now it is unrelated. But before the patch it wasnt. So "currently the SIGALRM handler..." means the current code in kvm-userspace.git. > >- Processing of IO events will not be unnecessarily interrupted. > > > > What do you mean by this? That SIGIO, SIGALRM and SIGUSR2 signals will not interrupt main_loop_wait(), since they are now blocked. Better latency, less time holding the mutex lock. ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
