Mikhail Ramendik wrote:
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.
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
_______________________________________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
