"Timothy J. Massey" wrote:
> One other thing. This ties into what Kevin said: that the solution he
> envisions would cause the same timing of interrupts from the VM's
> perspective: interrupts would occur at exactly the same code point as if the
> program were executing for real on the host hardware, just slower from the
> host's (and user's) perspective.
>
> The thing is, that is not necessarily the desired effect. In a solution like
> Bochs, that level of virtualization is critical. But in FreeMWare, this
> isn't necessarily the case. The interrupts *should* come faster; if the
> program were running on a slower CPU, the interrupts *would* come faster.
>
> How much faster is the question, and how much does this affect performance.
> I'm imagining that *that* is the purpose of a user-configurable agression
> factor?
>
> It also seems to me that the difference between a program's execution time
> under the VM and the actual hardware is a variable thing. It depends on not
> only the state of the host (how many processes, etc.) but also the code: the
> degree of virtualization that it will require.
Your and Ramon's comments are true to a degree and in certain
circumstances. It all depends on the guest OS, the workload
on the host OS, and the workload inside the guest OS from the
apps you are running. Bochs represents the extreme end of
the situation you can be in if you get too aggressive.
You point out that on a slower CPU the interrupts would come
faster. Well, that's true, but perhaps nowhere's near as
fast as you could feed them into the guest trying to catch up.
If you're only getting 10% of the processor for a while, the
VM would have to see interrupts occurring at over 10 times
the normal rate. In addition, certain guest OSes like Windows
are going to require more intervention via the monitor than
Linux. That will make the factor even higher.
What I think is being missed here, is that while in the VM, the guest
kernel level code like the interrupt handlers and scheduling
code is seeing 1/Nth of the processor time, when the host
OS load is N.
When the guest is running natively, it is used
to taking a certain amount of time to handle an interrupt and
scheduling even if the application load is high. For the
locality of the system code it is used to seeing 1/1 of the
processor time in native mode.
For the guest OS running natively, it *doesn't* matter how
much productive user code progress happens when the system
is bogged down; the kernel code will still receive interrupts,
and take a certain amount of time to process them. A slower
CPU will receive more interrupts per I instructions, so the
user code will suffer slower speed. That's life and big deal.
But what we are proposing here is that the guest OS system
code itself only gets 1/Nth of the CPU time, and thus will
effectively be handling interrupts and other tasks within
intervals N times smaller than they were before. The reason
the guest OS could handle it before, is due to the priority
of the interrupts pre-empting the application code. But
we have lost this priority due to the fact that we have been
dumbed down to a user application under the host OS.
Load inside the guest is *not* the same as load outside.
To make things worse, each interrupt we feed the guest OS
makes a bunch of things happen which we have to virtualize
in the monitor. Each of these things creates an exception,
and some overhead of processing that exception. Each
transition from ring3 to ring0. Each execution of a protected
instruction. Each access to a virtualized structure such as
the page tables, GDT, IDT, etc. Execution of more guest OS code
is the last thing we want to do, since it is were a majority
of the virtualization overhead occurs!
All that said, I am agreeing with you folks that we can
easily add some skewing code to the timing facilities. For
cases where N is not too great, it will probably do. But
we have to user our heads about this. Let's be able to turn
it off. And let's be ready to give up on catching up when
necessary, then start tracking again.
My prediction is that guesting Windows is going to really
suck performance-wise when you aggressively track the host OS
time frame, and the host OS load goes up.
What will probably help out are Windows specific drivers for
video and sound.
-Kevin
