[Qemu-devel] BeOS/Zeta eats 100% cpu time

[Qemu-devel] BeOS/Zeta eats 100% cpu time

[Christian Wiese]

Hello list,

hope this is the right place to tell you the behaviour of qEmu running 
BeOS. If not, please ignore it ;-)
So I finally got BeOS (Zeta) installed (longer story ;-)) and it works, 
but only very slow. The strange thing is, that it uses the 100% of my 
host cpu all the time. The HLT instruction is used by BeOS btw.
So I would like to test where (and why) this is happening. I tried to 
compile with cygwin, but I didn´t get it (and I would not like to 'mess' 
my system with another "gnu-emulation-suite"). And even if I get it, I 
wouldn´t really know where to search.
So maybe someone got an idea and we can find the problem together :-)

Greetings,
 Chris

Re: [Qemu-devel] BeOS/Zeta eats 100% cpu time

[André Braga]

That one is simple: you're booting in either monochrome or VESA mode,
because there's no native accelerated driver for the videocard QEMU
emulates, and BeOS does indeed use 100% CPU in this case. I don't know
what are the details under the hood, but this is a known fact.

You could try compiling QEMU with MingW instead of cygwin, as it
should work out of the box and the toolchain setup is not as
complicated or lenghty.


cheers,

-- 
"Dealing with failure is easy: Work hard to improve. Success is also
easy to handle: You've solved the wrong problem. Work hard to improve"
Alan J. Perlis




On Thu, 30 Sep 2004 15:32:22 +0200, Christian Wiese <developlists@gmx.de> wrote:
> Hello list,
> 
> hope this is the right place to tell you the behaviour of qEmu running
> BeOS. If not, please ignore it ;-)
> So I finally got BeOS (Zeta) installed (longer story ;-)) and it works,
> but only very slow. The strange thing is, that it uses the 100% of my
> host cpu all the time. The HLT instruction is used by BeOS btw.
> So I would like to test where (and why) this is happening. I tried to
> compile with cygwin, but I didn´t get it (and I would not like to 'mess'
> my system with another "gnu-emulation-suite"). And even if I get it, I
> wouldn´t really know where to search.
> So maybe someone got an idea and we can find the problem together :-)
> 
> Greetings,
>  Chris
>

Re: [Qemu-devel] BeOS/Zeta eats 100% cpu time

[Christian Wiese]

André Braga wrote:

>That one is simple: you're booting in either monochrome or VESA mode,
>because there's no native accelerated driver for the videocard QEMU
>emulates, and BeOS does indeed use 100% CPU in this case. I don't know
>what are the details under the hood, but this is a known fact.
>
>  
>
Hmm. That could be a reason. But a strange thing is, that BeOS itself 
thought that it is using only little amount of cpu-time. And for example 
vmWare has no problem with this. So, could there be a second problem?
Btw. I´ve found in the sources that now there is a Cirrus GraKa 
emulated. But before there were a S3 (?). Was the S3 running? Or is it 
possible to use the S3 emulation? I think there was a S3 driver for BeOS...

Thanks so far,
 Chris

Re: [Qemu-devel] BeOS/Zeta eats 100% cpu time

[André Braga]

Uh, so you meant having 100% use of CPU on the host machine?

That could be explained by acceleration too. AFAIK, on VESA/monochrome
mode, BeOS has to repaint the entire screen every time something
changes (like the clock on the deskbar). This is not that heavy on the
guest CPU, but on the emulated bus timings and         video
bandwidth, which IMO is the biggest bottleneck of QEMU. That could be
the reason, but I may be wrong on my assertment.

There are drivers for several S3 models available to BeOS, but those
are hardly all the models made by S3. The only two solutions I can
think of is to write a new graphic card emulation layer for QEMU,
which supports the instruction set of a specific, supported card on
BeOS, or to write a new driver for BeOS which drives the Cirrus card
QEMU currently emulates.


-- 
"Wherever you go, There you are"
Buckaroo Banzai



On Thu, 30 Sep 2004 17:53:06 +0200, Christian Wiese <developlists@gmx.de> wrote:
> Hmm. That could be a reason. But a strange thing is, that BeOS itself
> thought that it is using only little amount of cpu-time. And for example
> vmWare has no problem with this. So, could there be a second problem?
> Btw. I´ve found in the sources that now there is a Cirrus GraKa
> emulated. But before there were a S3 (?). Was the S3 running? Or is it
> possible to use the S3 emulation? I think there was a S3 driver for BeOS...
> 
> Thanks so far,
> 
> 
>  Chris

Re: [Qemu-devel] BeOS/Zeta eats 100% cpu time

[Christian Wiese]

André Braga wrote:

>Uh, so you meant having 100% use of CPU on the host machine?
>
>  
>
Sorry to be imprecise. The guest (BeOS) is more or less in an idle 
state. The host (WinXP) uses 100% cpu time.

>That could be explained by acceleration too. AFAIK, on VESA/monochrome
>mode, BeOS has to repaint the entire screen every time something
>changes (like the clock on the deskbar). This is not that heavy on the
>guest CPU, but on the emulated bus timings and         video
>bandwidth, which IMO is the biggest bottleneck of QEMU. That could be
>the reason, but I may be wrong on my assertment.
>
>  
>
No, I don´t think so, because even if I minimize the qEmu window and 
nothing changes in BeOS (clock changes only every minute, not second), 
the host-CPU is at 100%.

>There are drivers for several S3 models available to BeOS, but those
>are hardly all the models made by S3. The only two solutions I can
>think of is to write a new graphic card emulation layer for QEMU,
>which supports the instruction set of a specific, supported card on
>BeOS, or to write a new driver for BeOS which drives the Cirrus card
>QEMU currently emulates.
>
>  
>
I meant:  is it possible to activate the old S3 card emulation or was it 
never finished? Because when it is possible, I can search for a driver. 
If not, I´ll try to write a Cirrus driver, but this would take some 
time, because I´m just looking into some network-driver development.

Greetings,
 Chris

Re: [Qemu-devel] BeOS/Zeta eats 100% cpu time

[André Braga]

On Thu, 30 Sep 2004 19:27:23 +0200, Christian Wiese <developlists@gmx.de> wrote:
> Sorry to be imprecise. The guest (BeOS) is more or less in an idle
> state. The host (WinXP) uses 100% cpu time.


OK, so before I jump in saying contradictory statements:
On VESA/grayscale modes, anything doing rapid video refreshes will tax
the CPU. Like playing a video, watching the Chart, moving windows,
anything like that. I'm surprised that your BeOS was just sitting
idle!

> No, I don´t think so, because even if I minimize the qEmu window and
> nothing changes in BeOS (clock changes only every minute, not second),
> the host-CPU is at 100%.

This is strange, but now I have another idea: maybe it's requesting
the hardware to indeed repaint the screen with a 60 times a second, as
by the 60Hz refresh rate to which it defaults when using VESA modes.

SDL might not be handling this intelligently, or maybe it's the
graphics emulation or the Cirrus BIOS; anyway, QEMU goes idle when I
boot a console-mode OS, and goes for 100% CPU when I boot any
graphical OS, BeOS included.

> I meant:  is it possible to activate the old S3 card emulation or was it
> never finished? Because when it is possible, I can search for a driver.
> If not, I´ll try to write a Cirrus driver, but this would take some
> time, because I´m just looking into some network-driver development.

I have no idea. Sorry :)


-- 
"Structure is nothing if it is all you've got. Skeletons spook people
if they try to walk around on their own; I really wonder why XML does
not"
Erik Naggum

RE: [Qemu-devel] BeOS/Zeta eats 100% cpu time

[Andreas Bollhalder]

I use GEOS (it's a G and not a
B) with the VESA drivers in
800x600x16bit resolution on my
1.2GHz notebook. It performs
very well and the grafic delay
is at a minimum. The HLT
instruction is done by the
FreeDOS FDAPM utility. Without
that, my host would be on 100%
CPU usage too.

Andreas

Re: [Qemu-devel] BeOS/Zeta eats 100% cpu time

[Christian Wiese]

André Braga wrote:

>SDL might not be handling this intelligently, or maybe it's the
>graphics emulation or the Cirrus BIOS; anyway, QEMU goes idle when I
>boot a console-mode OS, and goes for 100% CPU when I boot any
>graphical OS, BeOS included.
>  
>
Don´t think so, because if I run ReactOS in VESA mode, qEmu won´t use 
100% of the host CPU. So there must be something else, which causes this 
huge overhead.
Maybe I find some time to build an profiling-enabled version.

Greetings,
 Chris

Re: [Qemu-devel] BeOS/Zeta eats 100% cpu time

[André Braga]

Please :)

-- 
"Logic: merely enables one to be wrong with authority"
Doctor Who



On Fri, 01 Oct 2004 10:14:50 +0200, Christian Wiese <developlists@gmx.de> wrote:
> Don´t think so, because if I run ReactOS in VESA mode, qEmu won´t use
> 100% of the host CPU. So there must be something else, which causes this
> huge overhead.
> Maybe I find some time to build an profiling-enabled version.

Re: [Qemu-devel] BeOS/Zeta eats 100% cpu time

[Christian Wiese]

Christian Wiese wrote:

> Maybe I find some time to build an profiling-enabled version.

Hmm, when I  set -p or -pg for profiling and remove 
-fomit-frame-pointer, the created op.h is empty and dyngen crashes 
because of this. Does someone now why this happen and what I can do to 
get a profiling-executable?

Greetings,
  Chris

Re: [Qemu-devel] BeOS/Zeta eats 100% cpu time

[Paul Brook]

On Friday 01 October 2004 22:06, Christian Wiese wrote:
> Christian Wiese wrote:
> > Maybe I find some time to build an profiling-enabled version.
>
> Hmm, when I  set -p or -pg for profiling and remove
> -fomit-frame-pointer, the created op.h is empty and dyngen crashes
> because of this. Does someone now why this happen and what I can do to
> get a profiling-executable?

Don't profile op.c. It's fairly sensitive to compiler options, and isn't 
directly linked into qemu anyway. I ran into similar problems when building a 
debuggable qemu.

Paul

Re: [Qemu-devel] BeOS/Zeta eats 100% cpu time

[Johannes Schindelin]

Hi,

On Fri, 1 Oct 2004, Paul Brook wrote:

> Don't profile op.c. It's fairly sensitive to compiler options, and isn't
> directly linked into qemu anyway. I ran into similar problems when building a
> debuggable qemu.

If you are working on Linux, try oprofile. You don't have to compile
differently then, and get detailed results.

Ciao,
Dscho

Re: [Qemu-devel] BeOS/Zeta eats 100% cpu time

[Christian Wiese]

Paul Brook wrote:

>Don't profile op.c. It's fairly sensitive to compiler options, and isn't 
>directly linked into qemu anyway. I ran into similar problems when building a 
>debuggable qemu.
>  
>
Ok, I now configure with --enable-gprof and it compiled fine. But as it 
looks like gprof writes it prof.out file when the executable close I 
have a new problem. BeOS do not "close" qEmu so that I have to kill the 
running process (with the "x" in the titlebar) and no file is writen. So 
does someone now a way to exit qEmu in a "normal" way, so that gprof 
will write it´s values into a file?

Greetings,
 Chris

Re: [Qemu-devel] BeOS/Zeta eats 100% cpu time

[Johannes Schindelin]

Hi,

On Sun, 3 Oct 2004, Christian Wiese wrote:

> Ok, I now configure with --enable-gprof and it compiled fine. But as it
> looks like gprof writes it prof.out file when the executable close I
> have a new problem. BeOS do not "close" qEmu so that I have to kill the
> running process (with the "x" in the titlebar) and no file is writen. So
> does someone now a way to exit qEmu in a "normal" way, so that gprof
> will write it´s values into a file?

If you go to QEmu's monitor, you can issue the "quit" command. The
monitor can be reached with Ctrl+Shift+F2 (in my setup, I have to make
sure there is a delay between Ctrl and Shift). Another option is to start
qemu with "-monitor stdio"; you will then see the prompt right away.

Hth,
Dscho

Re: [Qemu-devel] BeOS/Zeta eats 100% cpu time

[Christian Wiese]

Johannes Schindelin wrote:

>If you go to QEmu's monitor, you can issue the "quit" command.
>
Thanks, but I´ve thought of that, too. I was under the impression that 
this call will kill the process and not shut down gracefully. But after 
compiling with --enable-gprof and without, both executables have exactly 
the same size, so it looks like profiling isn´t enabled at all.
So if someone has allready a profiled exe for windows and would be so 
kind to send it to me, I will appreciate it very much.

Greetings,
  Chris