Ramon van Handel wrote:
> Tight loops (the BogoMIPS loop) are only used for very short
> delays anyway (and they have always been) --- it would not only
> be a waste of VM time if they were used for longer ones,
> it would be a waste of "ordinary" CPU time as well!!
> Tight loops are only used when you can't do anything useful
> in the meantime anyway, and for such situations the VM could
> not make it more efficient either. Longer delays are handled
> by the scheduler, which will run the idle thread (calling HLT)
> if it has nothing better to do.
>
> My opinion: don't worry about it --- it's not worth it.
I'm not sure we should forget about this. Here's how
udelay() is implemented in 2.2 and 2.4 kernels, if
RDTSC is available:
static void __rdtsc_delay(unsigned long loops)
{
unsigned long bclock, now;
rdtscl(bclock);
do
{
rdtscl(now);
}
while((now-bclock) < loops);
}
There are a number of kernel drivers which call udelay().
If we're trapping RDTSC, then performance would be horrible.
To make the above loop work, we'd need to let the guest
read it by enabling user reads in CR4. Then save/restore
the real TSC when transitioning from kernel<-->monitor.
I guess that would be easy enough.
I'd like to make sure loop code was stored in it's own page,
and didn't cross a page boundary, though. There are some
simple tips like this that would ensure guest code will run efficiently
inside plex86.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Kevin Lawton [EMAIL PROTECTED]
MandrakeSoft, Inc. Plex86 developer
http://www.linux-mandrake.com/ http://www.plex86.org/
