On Wed, 21 Apr 1999 [EMAIL PROTECTED] wrote:
> I've installed dosemu-0.99.10.0 on my RH5.2 box, the kernel
> upgraded to 2.2.5, and started xdos, with in the configuration file:
>
> $_rdtsc = (on) # if possible use Pentium cycle counter
> $_hogthreshold = (100) # 0 == all CPU power to DOSEMU
$_hogthreshold = (1) gives all power to Linux (see doc/README.txt)
and with this I see a load of 0.05 on my machine, when idling on the DOS
prompt.
> $_com1 = "/dev/vmodem" # e.g. "/dev/mouse" or "/dev/cua0"
>
> This xdos seems to slow down the system much, even when at the DOS
xdos eats 'X-power' (counts to the CPU load of the server), because
it has to refresh the screen quite often, much more then other X
applications (except real video of course;-). The config value to play
with is
$_X_updfreq = (5)
However, if you make the refresh rate big (value small), you eat more
X-power, if you make it too small (value big), you get a noticable delay
when the X-server has to wait for the X-application to finish some action.
It may depend on the X-server used though.
> prompt doing nothing: dragging a window on my K6-2 333Mhz 128Mb slows
> down alot [gfx card: Matrox G200], it looks like it spends a lot of
> time in kernel space since it is not traceable with top.
Yes, _quite_ a lot. Though it drops kernel priviledges and uses userspace
pagetables, it doesn't really return to the _32-bit_ userspace code while
in vm86(). It's a special case not 1:1 comparable with normal userspace.
And while in vm86() the CPU time apparently counts as 'kernel time'.
> [root@k6 fd]# ls -l /proc/1347/fd/12
> lrwx------ 1 root root 64 Apr 21 21:30 /proc/1347/fd/12 ->
>/dev/vmodem
>
> ..so it's polling the COM port for no reason. Someone knows why?
The reason is you configured to use it, and depending on what serial
drivers / TSRs you have, there is no other way as to poll.
> SYS_166(0x1, 0x8106d44, 0x70000, 0xfff8fff1, 0x804bd00) = -1 ENOSYS (Function not
>implemented)
> gettimeofday({924723197, 781803}, NULL) = 0
>
> etc.
>
> It seems like this SYS_166 is the offending system call. Anyone knows
> what SYS_166 is supposed to do?
It's the heart of vm86() ;-) and it's returning -1 on 99.99 % of its calls.
Why the strace / libc maintainers after over 2 years could not cope with
finally knowing what this 'strange' syscall 166 does, is out of the scope
of my knowledge ;-)
Hans
<[EMAIL PROTECTED]>
