According to htop, QEmu has two processes that collectively use ~200% CPU time on the host, even when AmigaOS is idle. That's basically 2 cores being hogged all the time, even when doing nothing.
Does anyone else have this? What is QEmu doing that takes up all that CPU time? I would have expected host CPU usage to be low when the guest OS is idle.
@Hans No idea about QEmu, nor current real NG hardware (X1000, X5000, A1222), but on the old systems (classic Amiga, AmigaOne, Sam4x0, Pegasos2) AmigaOS 4.x is never idle. If nothing else is running the priority -127 idle.task, a NOP loop, is executed.
Only exception: If you are using my CPUTemp.docky (maybe there are similar tools doing the same as well) it replaces the ExecSG idle.task busy loop on supported CPUs with an implementation stopping the CPU (power saving mode) until the next interrupt restarts it.
Yes, the idle.task is indeed the culprit. The Tequila profiler shows the idle.task at the top. Sadly, hieronymus doesn't work for me (either it doesn't work on the Pegasos 2, or doesn't work on QEmu).
I'll try the CPUTemp docky.
Another oddity that I've noticed, is that moving the mouse pointer lowers the CPU usage of the second qemu process (at least with the SM501), as does drawing a lot of graphics (at least with VirtioGPU).
@joerg I just tried the CPUTemp docky on os4depot, and the idle.task is still eating up all free CPU time. Looks like there's no easy way to disable it.
I just tried the CPUTemp docky on os4depot, and the idle.task is still eating up all free CPU time. Looks like there's no easy way to disable it.
Which (emulated) CPU? IIRC the power saving code in it was only working/used on 603e, 750FX and 750GX CPUs, not on 604e and 74xy CPUs. Not sure about 750CXe any more, the THRM registers aren't supported/working, power saving mode may.
I don't know if QEmu supports emulating the power saving modes at all, or in a way that it's stopping the emulated CPU like real CPUs do.
Even if it's working you can't check CPU usage with tools like Tequila as that's restarting the CPU 5000 times/sec. with timer.device interrupts and the CPU usage calculation method it's using doesn't work if the CPU is stopped. Don't use such AmigaOS tools but check the host CPU usage instead.
If the guest OS does something (like "stop" on 68k, or "hlt" on x86) which lets a real cpu know that it is supposed to sleep (until interrupt happens), then an emulation of that cpu can know, too.
Here MorphOS in qemu (-machine mac99) shows about 8 .. 9 % qemu cpu usage on host with htop.
AROS Sam PPC in qemu (-machine sam460ex) shows about 5 .. 6 % qemu cpu usage on host with htop.
According to htop, QEmu has two processes that collectively use ~200% CPU time on the host, even when AmigaOS is idle. That's basically 2 cores being hogged all the time, even when doing nothing.
Does anyone else have this? What is QEmu doing that takes up all that CPU time? I would have expected host CPU usage to be low when the guest OS is idle.
I wouldn't even worry about it. Modern operating systems are able to distribute this across their cores. Of course, there is a limit. For example the Apple M1 MacOs. I have no idea how they do it on "x86" (Window...). Linux is a matter of cpu sheduler and kernel (sheduler = not only those included in the stable/official release of the kernel in the distros) ....
Which (emulated) CPU? IIRC the power saving code in it was only working/used on 603e, 750FX and 750GX CPUs, not on 604e and 74xy CPUs. Not sure about 750CXe any more, the THRM registers aren't supported/working, power saving mode may.
I don't know if QEmu supports emulating the power saving modes at all, or in a way that it's stopping the emulated CPU like real CPUs do.
Ranger says: PowerPC 74XX Apollo
Quote:
Even if it's working you can't check CPU usage with tools like Tequila as that's restarting the CPU 5000 times/sec. with timer.device interrupts and the CPU usage calculation method it's using doesn't work if the CPU is stopped. Don't use such AmigaOS tools but check the host CPU usage instead.
I checked htop when Tequila wasn't running. QEmu was still using 200% CPU on the host. Then I started Tequila, and it showed idle.task at the top.
Quote:
PerformanceMonitor.resource, which is used by tools like Hieronymus, isn't supported on all systems. According to a comment on http://os4depot.net/?function=comment ... ment/debug/hieronymus.lha from 10 Nov 2012 by kas1e Pegasos2 is one of the unsupported ones.
That's a pity, because hieronymus can tally up CPU usage on a per-function basis when debug symbols are available.
@Georg Quote:
If the guest OS does something (like "stop" on 68k, or "hlt" on x86) which lets a real cpu know that it is supposed to sleep (until interrupt happens), then an emulation of that cpu can know, too.
Exactly. I'd forgotten about idle.task, which is a bad idea because it prevents CPU power management from working.
@smarkusg Quote:
I wouldn't even worry about it. Modern operating systems are able to distribute this across their cores. Of course, there is a limit. For example the Apple M1 MacOs. I have no idea how they do it on "x86" (Window...). Linux is a matter of cpu sheduler and kernel (sheduler = not only those included in the stable/official release of the kernel in the distros) ....
It's certainly not affecting the usability of my system, but it wasn't the behaviour that I was expecting. I was wondering if there was something wrong with the emulation that, if solved, might boost performance.
on the old systems (classic Amiga, AmigaOne, Sam4x0, Pegasos2) AmigaOS 4.x is never idle. If nothing else is running the priority -127 idle.task, a NOP loop, is executed.
Hmm, that probably explains why when I start Amiga Forever/WinUAE emulating an A4000PPC running OS4 on my wife's laptop, the fan starts spinning loudly as long as the emulator is running, even if I don't do anything in it.
Quote:
IIRC the power saving code in it was only working/used on 603e, 750FX and 750GX CPUs, not on 604e and 74xy CPUs.
So it looks like it wouldn't help in my case to use CPUTemp.docky, as my emulated CPU must be a 604e.
You could change the emulated CPU to a 750FX or 750GX and check if CPUTemp.docky can help reducing the host CPU usage.
Make sure the IGNORETASKS tooltype isn't used. With it CPUTemp.docky calculates the CPU usage itself. I don't remember the details, but it's probably something similar to what Tequila does. Without it CPUTemp.docky displays the CPU usage calculated by the ExecSG task scheduler.
Quote:
That's a pity, because hieronymus can tally up CPU usage on a per-function basis when debug symbols are available.
gprof probably depends on PerformanceMonitor.resource as well.
I always wrote Pegasos2 is the worst possible OS4 system to emulate with QEmu. - No OS4 developers, except for the Friedens, had one. - Next to no OS4 beta testers, if any at all, had one. - Only firmware without access to the sources, and AmigaOS 4.x depends a lot on the firmware. May have resulted in problems in the exansion.library PCI functions for example. Using a PCIe gfx card with PCI->PCIe bridge works on real Sam440 and AmigaOne XE (not really usable because of the A1 hardware bugs, but it's working), on the Pegasos2 it doesn't work. - PerformanceMonitor.resource may not be the only OS4 part not supported on the Pegasos2, real and emulated. - Endian bugs on 15/16 bit screen modes, for example with software using SDL1 (QEmu only, not on real hardware). - Probably more I forgot.
The only major problem with the AmigaOne and Sam460 emulation in QEmu is probably the missing NVRAM support. Sam460 emulation is just slower because 405/4x0 CPUs have no usual MMU.
So it looks like it wouldn't help in my case to use CPUTemp.docky, as my emulated CPU must be a 604e.
I don't know if it would be working on 604e as well, according to the readme it just wasn't tested with a 604e CPU. Probably no beta tester with one and I only enabled it for the CPUs on which it was tested successfully.
That's a pity, because hieronymus can tally up CPU usage on a per-function basis when debug symbols are available.
Did you test Tequila's PROFILE switch, by the way? I added simple profiling support because Hieronymus didn't work on my systems initially (but it was luckily updated later and started to work).
Hans wrote: I just tried the CPUTemp docky on os4depot, and the idle.task is still eating up all free CPU time. Looks like there's no easy way to disable it.
It may be that AOS4 requires an idle task (one that is always TS_READY), if it otherwise doesn't know how to handle the case of no-ready-task-to-run. Unlike AOS3 which handles it in exec/Dispatch() (loop until there is one with "stop" instruction inside the loop to sleep until interrupt happens which can cause some task to become ready).
If not, "Disable(), Remove(FindTask("idle_task_name")), Enable()" should disable it (without really killing it).
Or write your own idle task which priority 1 highter than the system one. And in your idle task have a loop which inside calls the whatever PPC instruction(s) which cause the cpu to go to sleep on qemu (maybe the emulated cpu handles such instructions even for cpus that in real life don't have them).
It may be that AOS4 requires an idle task (one that is always TS_READY), if it otherwise doesn't know how to handle the case of no-ready-task-to-run. Unlike AOS3 which handles it in exec/Dispatch()
ExecSG has no Dispatch() function, at least none which does the same as AmigaOS 0.x-3.9 did.
Quote:
If not, "Disable(), Remove(FindTask("idle_task_name")), Enable()" should disable it (without really killing it).
AFAIK the ExecSG task scheduler only works if there is always a ready task, if you do that the task scheduler will likely crash.
Quote:
Or write your own idle task which priority 1 highter than the system one. And in your idle task have a loop which inside calls the whatever PPC instruction(s) which cause the cpu to go to sleep on qemu (maybe the emulated cpu handles such instructions even for cpus that in real life don't have them).
What I did in CPUTemp.docky is to highjack the idle.task by setting it's IP to my code which is an endless loop as well, but one stopping the CPU (IIRC I used the DOZE mode because with NAP and SLEEP modes the timer.device interrupts, which are based on CPU features, were stopped as well and the CPU was only restarted by external HW interrupts like PCI ones) instead of a busy NOP loop. All PowerPC CPUs support power saving modes, but different ones may need different bits set or cleared in the MSR register, or something else. Or maybe not all CPUs support DOZE but only NAP and SLEEP, which didn't work in my tests. My CPUTemp.docky code was only tested on 603e and 750 CPUs and therefore replacing the idle.task code is disabled on all other CPUs.
Did you test Tequila's PROFILE switch, by the way? I added simple profiling support because Hieronymus didn't work on my systems initially (but it was luckily updated later and started to work).
I did a long time ago, and can't remember what issues I encountered.
For what I'm measuring, I'd prefer something that doesn't open up a GUI window, and simply records the data for X number of seconds, and then reports what happened.
I think performance counters of PPC CPUs aren't emulated with TCG and it's proabably not easy to implement as it runs JIT compiled code so it does not know how many guest instructions it corresponds to which the performance counters should count. A sampling profiler that does a backtrace periodically should work but tools that rely on performance counters won't work. I think this was discussed before.
QEMU has one thread per vcpu and a main thread. If the vcpu always runs code it will be busy. If it also does some IO like accessing emulated hardware registers then the main thread will also have to run. This may explain why waiting for IO may lower the vcpu usage as then the vcpu may sleep instead of running the idle loop.
It looks like this may also be an issue on real machine which would use more power and keep the system run hotter instead of letting the CPU sleep when idle so maybe it should be fixed for the real machine too independent of QEMU. (Unless it does use something that works on real machine but not emulated by QEMU.)
It looks like this may also be an issue on real machine which would use more power and keep the system run hotter instead of letting the CPU sleep when idle so maybe it should be fixed for the real machine too independent of QEMU. (Unless it does use something that works on real machine but not emulated by QEMU.)
This absolutely should be fixed in the kernel itself. While it doesn't affect functionality, burning unused CPU cycles in a loop is a waste of energy.
QEMU has one thread per vcpu and a main thread. If the vcpu always runs code it will be busy. If it also does some IO like accessing emulated hardware registers then the main thread will also have to run. This may explain why waiting for IO may lower the vcpu usage as then the vcpu may sleep instead of running the idle loop.
No, if an AmigaOS task waits for IO the busy loop idle.task is running. The vcpu can only be stopped by QEmu itself, for example when accessing the emulated TimeBase TBU/TBL registers in the AmigaOS MicroDelay() function.
Quote:
It looks like this may also be an issue on real machine which would use more power and keep the system run hotter instead of letting the CPU sleep when idle so maybe it should be fixed for the real machine too independent of QEMU. (Unless it does use something that works on real machine but not emulated by QEMU.)
I implemented the power saving ide.task replacement and displaying the CPU core temperature in CPUTemp.docky after frying an AmigaOne XE G4 CPU module, the original CPU heat sink and fan used by EyeTech was inadequate and I didn't replace it. But that only was a problem when doing something real, like compiling code for several hours, not when doing nothing and only the idle.task busy loop is executed. In automatic power mode the PowerPC CPUs switch off or slow down all unused units, and just executing a busy loop can disable nearly all CPU units: All memory transfer units since the code is in the L1 cache and no data is accessed, all integer ALU units, all FPU units, the AltiVec units where available, the branch prediction and code prefetch unit, etc.
This absolutely should be fixed in the kernel itself. While it doesn't affect functionality, burning unused CPU cycles in a loop is a waste of energy.
I'm not sure, but I might have added my CPUTemp.docky idle.task replacement code in the ExecSG sources in a
#if 0
...
#endif
part (never used because my code doesn't work, or at least wasn't tested, on all CPUs, only on 603e and 750 CPUs). If you have access to the ExecSG source you could check it, or if not ask someone who has access.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
