Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!usenet.ins.cwru.edu!gatech!prism!gt8134b
From: gt8134b@prism.gatech.EDU (Howlin' Bob)
Newsgroups: comp.os.386bsd.development
Subject: Re: V86 mode
Message-ID: <107775@hydra.gatech.EDU>
Date: 6 Aug 93 18:45:48 GMT
References: <107725@hydra.gatech.EDU> <23tqbk$3tt@europa.eng.gtefsd.com>
Organization: Georgia Institute of Technology
Lines: 93
In <23tqbk$3tt@europa.eng.gtefsd.com> niemidc@oasis.gtefsd.com (David C. Niemi) writes:
>The V86-mode emulators I have seen tend to suck about 10% of the CPU each (on a 386).
>Is this inherent in V86 mode, or is it a deficiency of the implementation?
Well, it's too vague to answer. Are you talking about a running program
doing long computations with little I/O, or mostly I/O intensive programs
polling the keyboard for data?
V86 mode running a compute-intensive program on an otherwise unloaded system
will take 99% of the CPU. The same program running ona machine with a couple
of compilations going will take much less... the one principle that makes
multitasking worth the overhead is this: most programs spend a significant
amount of time waiting for I/O to complete; it is possible to run other
programs during these "dead times" with little disturbance to the
waiting process(es). That is, there's a lot of CPU time being wasted
by our slow peripherals, so we might as well fill it with other
programs (which will wait for I/O...). This is the most CPU intensive
program you can write:
while(1) ;
but this is about the cheapest:
while(1)
sleep(1);
I'm sure you already know all this, butit's worth restating here because
it's totally applicable. The one problem is that DOS programs aren't
very well-versed on multitasking-friendly ways of waiting for I/O
to complete.
The average DOS program running under dosemu spends most of its time
doing a couple of things:
1) Updating the screen
2) Checking for keyboard input
The first can't be helped much; it has to do what it has to do. The second
however, can be helped. DOS programs tend to busy-wait by calling the
non-blocking int16h "key ready?" function, which can take quite a tool
on the CPU. dosemu employs a scheme similar to the one used in the
DOS program TAME: it will keep track of the times between calls to int16h,
and if this time falls below a certain threshold value, it will make
subsequent calls to int16h sleep for a short time. This has the effect
of releasing the CPU for other programs to use. Unfortunately, dosemu
cannot simply block waiting for input, as many programs poll for keyboard
input as part of their "main loop"; the threshold is supposedly chosen
so that application performance does not suffer much, but system load
is reduced significantly. In practice, the default threshold seems to
give acceptable results on my system, but I can notice some slight hesitation
in some programs: notably, Turbo C/Pascal run slower in the PageUp/PageDown
operations.
I have seen dosemu start up at 99% CPU use (a fairly useless number), idle
a second or two, then drop down to 0.5% CPU usage. Keyboard entry will
cause the TAME algorithm to be temporarily disabled, and CPU hoggishness
fluctuates considerably during that time, as the anti-hogging algorithm
takes a little while to reach an equilibrium. The real test is that I
can leave dosemu running in the background under most circumstances with
an acceptable effect on performance.
It should be noted that most "well-behaved" programs spend a good bit of
time calling BIOS/DOS routines through the use of software interrupts.
Every software interrupt causes a trap into non-V86 protected mode
(technically, V86 mode is still protected mode), a signal to be delivered
to dosemu, some scheduling delay, my instruction handler to decode
and simulate the effects of the instruction, a return to V86 mode,
and the same process some time later for the privileged IRET
instruction. Also, many BIOS and DOS routines will call *other*
BIOS/DOS routines through software interrupts, further slowing things
down. Even worse, they will make repeated use of the CLI/STI
instructions to disable and enable external interrupt delivery;
these, too, must be handled by dosemu's privileged instruction
handler. So, you see, it's hardly free.
>In other words, have you gotten around this problem?
I'm afraid there is no way around the problem. V86 mode is inherently
somewhat expensive (a couple hundred clocks to switch in or out), and
and instruction decoding to handle privileged instructions is slower
than native execution, but the real cost is this: a busy-waiting program
cannot be made to behave itself. Any method you choose will
inevitably penalize some programs, making them so slow that they are
unusable or don't run at all. However, it is assumed that anyone
running dosemu has decided to sacrifice a small slice of her CPU.
--
Robert Sanders
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt8134b
Internet: gt8134b@prism.gatech.edu