Re: [PATCH 5/5] ioeventfd: Introduce KVM_IOEVENTFD_FLAG_SOCKET

[Avi Kivity <avi@redhat.com>]

On 07/14/2011 11:59 AM, Pekka Enberg wrote:
> On Thu, Jul 14, 2011 at 11:28 AM, Avi Kivity<avi@redhat.com>  wrote:
> >  On 07/14/2011 11:14 AM, Pekka Enberg wrote:
> >>
> >>  >
> >>  >    I'm talking about the real world.  Is any of this something that needs
> >>  >    optimization?
> >>
> >>  Yes. See Sasha's other email. We should have mentioned that in the
> >>  changelog.
> >
> >  It's completely unrealistic.  Sash and you are the only two people in the
> >  universe logging into the guest via a serial console and running benchmarks.
>
> Why does that matter? Why should we keep the emulation slow if it's
> possible to fix it?

Fixing things that don't need fixing has a cost.  In work, in risk, and 
in maintainability.  If you can share this cost among other users (which 
is certainly possible with socket mmio), it may still be worth it.  But 
just making something faster is not sufficient, it has to be faster for 
a significant number of users.

> It's a fair question to ask if the benefits
> outweigh the added complexity but asking as to keep serial emulation
> slow because *you* think it's unrealistic is well - unrealistic from
> your part!

Exactly where am I unrealistic?  Do you think there are many users who 
suffer from slow serial emulation?

> >>  >    1024 vcpus logging in via the serial console at 10Gbps.  Get real.
> >>
> >>  [...]
> >>
> >>  Huh, why are you bringing something like that up?
> >
> >  Because it's another example of an unrealistic approach on your part.  No
> >  real user is interested in 1024 vcpus, and no real user is interested in
> >  optimized serial console.  It's good that you are bringing up new ideas and
> >  new code, but adding code just for its own sake is not a good thing.
>
> *You* brought up 1024 vcpus using serial console! Obviously optimizing
> something like that is stupid but we never claimed that we wanted to
> do something like that!

Either of them, independently, is unrealistic.  The example of them 
together was just levantine exaggeration, it wasn't meant to be taken 
literally.

> As for 1024 vcpus, we already had the discussion where we explained
> why we thought it was a good idea not to have such a low hard vcpu
> limit for vcpus.

I can't say I was convinced.  It's pretty simple to patch the kernel if 
you want to engage in such experiments.  We did find something that 
works out (the soft/hard limits), but it's still overkill.

There's a large attitude mismatch between tools/kvm developers and kvm 
developers (or at least me): tools/kvm is growing rapidly, adding 
features and improving stability at a fast pace.  kvm on the other hand 
is mature and a lot more concerned with preserving and improving 
stability than with adding new features.  The fact is, kvm is already 
very feature rich and very performant, so we're at a very different 
place in the performance/features/stability scales.

-- 
error compiling committee.c: too many arguments to function