[Qemu-devel] w98se slow with kqemu, apparently some systems only

[Qemu-devel] 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.

-- 
Yours, Mikhail Ramendik

Re: [Qemu-devel] w98se slow with kqemu, apparently some systems only

[Mikhail Ramendik]

I wrote: 

> 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.

-- 
Yours, Mikhail Ramendik

Re: [Qemu-devel] w98se slow with kqemu, apparently some systems only

[Brad Campbell]

Mikhail Ramendik wrote:
> I wrote: 
> 
>> 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


-- 
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams

Re: [Qemu-devel] w98se slow with kqemu, apparently some systems only

[Mikhail Ramendik]

В сообщении от 14 мая 2006 16:45 Brad Campbell написал(a):

> 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).

-- 
Yours, Mikhail Ramendik

Re: [Qemu-devel] w98se slow with kqemu, apparently some systems only

[Dan Sandberg]

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