w98se slow with kqemu, apparently some systems only

[Mikhail Ramendik]

Hello,

There seems to be an issue with guest Windows 98 SE on qemu 0.8.1 and kqemu
1.3.0pre7, on a Linux host.

Windows 98 SE is visibly very slow; and when qemu is run with -no-kqemu, it is
actually faster.

I have this issue on two different systems:

- Intel Celeron 2400 CPU, 512M RAM, RH9-derived, kernel 2.6.11 with some
patches including -ck
- AMD Duron 650 CPU, 256M RAM, Debian sarge, vanilla kernel 2.6.15 (run with
-m 64)

On the Intel system I also installed NT 4.0 (in a different image) and it is
fast with kqemu. (It has mouse problems - invisible wall, erratic behaviour,
all intermittent - but I know this issue is quite different and patches
exist).

This same issue was also reported on the user forum:
http://qemu.dad-answers.com/viewtopic.php?t=1476

However, other people on IRC have reported that Win98SE is fast for them. In
fact I have transferred my Win98SE image to another person, who runs qemu CVS
and kqemu 1.3.0pre7 on Ubunto dapper; he reported that it runs fast.

This seems to be an issue on some systems only, but I could not isolate the
key setup difference. I would be most interested in helping to pinpoint the
problem. I am ready to run any tests/patches, and I have an archive of
various old Windows systems (backups...) that I can try on request; I can
also pull CVS if necessary.

[Mikhail Ramendik]

Post by Mikhail Ramendik
There seems to be an issue with guest Windows 98 SE on qemu 0.8.1 and kqemu
1.3.0pre7, on a Linux host.
Windows 98 SE is visibly very slow; and when qemu is run with -no-kqemu, it
is actually faster.

I forgot to mention that the CPU use as per "top" is constantly at 100%,
almost all of it by qemu, with over 60% in "system";

With guest NT4 (which is fast) the CPU use is near zero when the NT system is
idle.

[Brad Campbell]

Post by Mikhail Ramendik

Post by Mikhail Ramendik
There seems to be an issue with guest Windows 98 SE on qemu 0.8.1 and kqemu
1.3.0pre7, on a Linux host.
Windows 98 SE is visibly very slow; and when qemu is run with -no-kqemu, it
is actually faster.

I forgot to mention that the CPU use as per "top" is constantly at 100%,
almost all of it by qemu, with over 60% in "system";
With guest NT4 (which is fast) the CPU use is near zero when the NT system is
idle.

Do you have the idle driver loaded in win98 as per the qemu docs?
Otherwise it will use 100% cpu, where as NT based systems know how to hlt the processor

[Mikhail Ramendik]

Post by Brad Campbell
Do you have the idle driver loaded in win98 as per the qemu docs?
Otherwise it will use 100% cpu, where as NT based systems know how to hlt the processor

Thanks, I have done so now.

The situation has improved, the speed with kqemu and without kqemu is now
approximately the same; but it is still much worse than what was reported by
the person for whom kqemu actually works.

For me, with this driver, the bootup to the logon prompt takes about 15 sec,
and after the logon button is pressed, it takes about 12 sec more to get to
the desktop (and be able to work, not look at the hourglass). This does not
change whether -no-kqemu is used. For the person for whom it works, with the
same image - without the driver! - bootup took 6 sec to logon prompt, then 3
sec to desktop.

In fact the very first Windows bootup after the install, where it probably did
hardware detection, took nearly an hour. (kqemu was enabled).

[Dan Sandberg]

Post by Mikhail Ramendik
Hello,
There seems to be an issue with guest Windows 98 SE on qemu 0.8.1 and kqemu
1.3.0pre7, on a Linux host.
Windows 98 SE is visibly very slow; and when qemu is run with -no-kqemu, it is
actually faster.
- Intel Celeron 2400 CPU, 512M RAM, RH9-derived, kernel 2.6.11 with some
patches including -ck
- AMD Duron 650 CPU, 256M RAM, Debian sarge, vanilla kernel 2.6.15 (run with
-m 64)
On the Intel system I also installed NT 4.0 (in a different image) and it is
fast with kqemu. (It has mouse problems - invisible wall, erratic behaviour,
all intermittent - but I know this issue is quite different and patches
exist).
http://qemu.dad-answers.com/viewtopic.php?t=1476
However, other people on IRC have reported that Win98SE is fast for them. In
fact I have transferred my Win98SE image to another person, who runs qemu CVS
and kqemu 1.3.0pre7 on Ubunto dapper; he reported that it runs fast.
This seems to be an issue on some systems only, but I could not isolate the
key setup difference. I would be most interested in helping to pinpoint the
problem. I am ready to run any tests/patches, and I have an archive of
various old Windows systems (backups...) that I can try on request; I can
also pull CVS if necessary.

I can report the same thing with Windows XP host and Windows 98 guest on
an Pentium M 1,8 GHz.
With Qemu 0.8.1 Windows 98 now runs quite well in normal emulated mode
on this computer and actually much slower with kqemu service running.
Linux guests run faster with kqemu as it is supposed to be.
I still cannot use the -kernel-kqemu option on Windows XP host, but I
guess that is known issue.

Just a wild guess: Could the combination of Windows 98's memory
management and the Soft-MMU for kqemu generate badly aligned memory blocks?
The Delphi compiler that I am used to adds its own memory management to
guarantee properly aligned memory blocks with realloc() etc for the best
possible cache performance (I believe all block requests are
automatically aligned by 256-byte as default, at least it should be 8
byte=64-bit). Does anyone know how gcc do? Does it simply call the OS
routine? And how does the soft-MMU do it?
It is possible to read/write 16/32/64-bit data from a badly aligned
buffer, but it can create a serious performance penalty so maybe there
is a potential for speed improvements by doing it similar to the way
Borland does.

Regards
Dan