On 07/14/2011 11:59 AM, Pekka Enberg wrote:
On Thu, Jul 14, 2011 at 11:28 AM, Avi Kivity<avi@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
