Re: [Qemu-devel] Re: KVM call minutes for Feb 1

[Anthony Liguori]

On 02/03/2011 04:11 AM, Marcelo Tosatti wrote:
> On Tue, Feb 01, 2011 at 06:34:50PM +0100, Jan Kiszka wrote:
>    
> > On 2011-02-01 18:20, Anthony Liguori wrote:
> >      
> > > On 02/01/2011 11:03 AM, Jan Kiszka wrote:
> > >        
> > > > On 2011-02-01 17:53, Anthony Liguori wrote:
> > > >
> > > >          
> > > > > On 02/01/2011 10:36 AM, Jan Kiszka wrote:
> > > > >
> > > > >            
> > > > > > On 2011-02-01 16:54, Chris Wright wrote:
> > > > > >
> > > > > >
> > > > > >              
> > > > > > > KVM upstream merge: status, plans, coordination
> > > > > > > - Jan has a git tree, consolidating
> > > > > > > - qemu-kvm io threading is still an issue
> > > > > > > - Anthony wants to just merge
> > > > > > >      - concerns with non-x86 arch and merge
> > > > > > >      - concerns with big-bang patch merge and following stability
> > > > > > > - post 0.14 conversion to glib mainloop, non-upstreamed qemu-kvm will be
> > > > > > >      a problem if it's not there by then
> > > > > > > - testing and nuances are still an issue (e.g. stefan berger's mmio read issue)
> > > > > > > - qemu-kvm still evolving, needs to get sync'd or it will keep diverging
> > > > > > > - 2 implementations of main init, cpu init, Jan has merged them into one
> > > > > > >      - qemu-kvm-x86.c file that's only a few hundred lines
> > > > > > > - review as one patch to see the fundamental difference
> > > > > > >
> > > > > > >
> > > > > > >                
> > > > > > More precisely, my current work flow is to pick some function(s), e.g.
> > > > > > kvm_cpu_exec/kvm_run, and start wondering "What needs to be done to
> > > > > > upstream so that qemu-kvm could use that implementation?". If they
> > > > > > differ, the reasons need to be understood and patched away, either by
> > > > > > fixing/enhancing upstream or simplifying qemu-kvm. Once the upstream
> > > > > > changes are merged back, a qemu-kvm patch is posted to switch to that
> > > > > > version.
> > > > > >
> > > > > > Any help will be welcome, either via review of my subtle regressions or
> > > > > > on resolving concrete differences.
> > > > > >
> > > > > > E.g. posix-aio-compat.c: Why does qemu-kvm differ here? If it's because
> > > > > > of its own iothread code, can we wrap that away or do we need to
> > > > > > consolidate the threading code first? Or do we need to fix something in
> > > > > > upstream?
> > > > > >
> > > > > >
> > > > > >              
> > > > > I bet it's the eventfd thing.  It's arbitrary.  If you've got a small
> > > > > diff post your series, I'd be happy to take a look at it and see what I
> > > > > can explain.
> > > > >
> > > > >
> > > > >            
> > > > Looks like it's around signalfd and its emulation:
> > > >
> > > >          
> > > I really meant the compatfd thing.
> > >
> > > signalfd can't really be emulated properly so in upstream we switched to
> > > a pipe() which Avi didn't like.
> > >
> > > But with glib, this all goes away anyway so we should just drop the
> > > qemu-kvm changes and use the upstream version.  Once we enable I/O
> > > thread in qemu.git, we no longer need to use signals for I/O completion
> > > which I think everyone would agree is a better solution.
> > >        
> > Don't understand: If we do not need SIGIO for AIO emulation in threaded
> > mode, why wasn't that stubbed out already? If that helps reducing
> > worries about the signalfd emulation (which is likely a non-issue anyway
> > as anyone with serious workload should run a kernel with such support).
> >      
> qemu-kvm has this modification for performance reasons.
> SIGUSR2 can't be blocked otherwise. See example test case at
> https://patchwork.kernel.org/patch/20817/.
>    

That test-case is not realistic.  That's 10k signals per second.  With 
batching, we're at an I/O op rate that we're not even close to today.  I 
can guarantee that you won't find a real workload were you can actually 
measure the difference.

And keep in mind, the signal notification should go away so having this 
change in qemu-kvm really doesn't make sense.

Regards,

Anthony Liguori