Ulrich Weigand wrote:
> Why are you worrying about the performance of code that
> does nothing but wait? As long as we skew the values
> returned from RDTSC properly, that loop should run for
> exactly the same amount of (guest) wall-clock time, no
> matter whether it will take a million or a thousand
> passes through the loop ...
Two reasons. One is that I don't want the guest OS to run
slow in the VM. Under the wrong conditions performance
could be sluggish, only because of bogus delay loops.
A second reason is that there is a host OS running, which
may be able to schedule a user task to do something useful,
if the udelay() value is high. I don't want to bog down
the host OS either while wasting time virtualizing a
guest busy loop.
Given the RDTSC code in the Linux kernel, I think we'll
be cool without any changes except to let RDTSC execute
normally, and save/restore it during transitions between
host<-->monitor/guest.
-Kevin
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Kevin Lawton [EMAIL PROTECTED]
MandrakeSoft, Inc. Plex86 developer
http://www.linux-mandrake.com/ http://www.plex86.org/
