Howto keep the processor idle?

[mohammedisam]

Did you enable realtime sync in bochs?

I tried:

Code: Select all

vga: realtime=1

in my bochsrc.txt file before, it didn't change a thing: same high readings for cpu performance.

[Brendan]

Hi,

How do you know that it's busy?

I am testing my kernel using Bochs under Fedora Linux. The GNOME System Monitor shows that at any given time (when my kernel is active) one of my quad processors is running at 100%. When I pause Bochs, the activity returns to its baseline (3-4%). If it runs for a while, all my other programs would considerably slow down, so I have to test my kernel after I close other windows.

So Bochs is spending 100% of host CPU time emulating devices (e.g. updating the screen, checking if an IRQ occurred, etc) and the guest CPU is spending most of it's time idle.

The "most correct" way to determine CPU utilisation is with performance monitoring counters. Specifically; setup one counter to count "non-halted clock ticks" and another to count "total clock ticks". CPU load is "non_halted / total". Unfortunately performance monitoring counters are model specific (you'd need different code for different CPUs) and aren't emulated by Bochs, so this would be very painful to implement.

If you have a specific "idle task", then an extremely easy alternative is to keep track of how much CPU time each task consumes (which is something you should be doing anyway); and then determine CPU load as "(total - idle) / total". Of course this will be a lot less accurate (e.g. time taken by IRQ handlers that interrupt the idle task will be counted as "idle time"); unless you keep track of "user time" and "kernel time" separately for each task and also use a very precise time source (like the CPU's TSC and not the "only updated every 10 ms" PIT timer count).

Most emulators, especially Bochs, will use all available CPU power even when the emulated CPU is supposed to be idle.

Looks like I will have to live with it. I cannot risk testing it on physical device yet.

Why?

Except for a few obvious cases (e.g. you're trying to implement hard disk drivers that write to the disk) there's almost no risk involved in testing on real computers. By not testing on real computers there's a high risk of undiscovered bugs.


Cheers,

Brendan

[SpyderTL]

Try testing on VirtualBox. If your virtual CPU is halted between interrupts, your VirtualBox host CPU usage will got to zero, or close to it.

[FallenAvatar]

...

Code: Select all

vga: realtime=1

in my bochsrc.txt file before, it didn't change a thing: same high readings for cpu performance.

How would even think that would make sense to even try!? Learn to read documentation!

- Monk

[mohammedisam]

If you have a specific "idle task", then an extremely easy alternative is to keep track of how much CPU time each task consumes (which is something you should be doing anyway); and then determine CPU load as "(total - idle) / total". Of course this will be a lot less accurate (e.g. time taken by IRQ handlers that interrupt the idle task will be counted as "idle time"); unless you keep track of "user time" and "kernel time" separately for each task and also use a very precise time source (like the CPU's TSC and not the "only updated every 10 ms" PIT timer count).

I haven't implemented this feature yet (keeping track of task times), though I see now this is the next step I should do.
Just to make sure I got this right: it is normal for emulators to keep the host CPU busy, though this doesn't reflect the normal behavior on a real physical device, right?.

Except for a few obvious cases (e.g. you're trying to implement hard disk drivers that write to the disk) there's almost no risk involved in testing on real computers. By not testing on real computers there's a high risk of undiscovered bugs.

actually, this is exactly the case. My disk drivers are still under development this is why I am not eager to try it on my physical drive yet. I am still in the phase of testing on virtual disk images.

Thanks for the info Brendan.

[mohammedisam]

Try testing on VirtualBox. If your virtual CPU is halted between interrupts, your VirtualBox host CPU usage will got to zero, or close to it.

I will. Thanks man .

[onlyonemac]

Just to make sure I got this right: it is normal for emulators to keep the host CPU busy, though this doesn't reflect the normal behavior on a real physical device, right?

That depends on the emulator, but as we've already mentioned Bochs will keep the host CPU busy while according to SpyderTL VirtualBox apparently lets the host CPU idle when the emulated CPU is idle.

actually, this is exactly the case. My disk drivers are still under development this is why I am not eager to try it on my physical drive yet. I am still in the phase of testing on virtual disk images.

Define "disk drivers". If you mean floppy disk drivers, then there's no reason not to test on real hardware. If you mean hard disk drivers, then pull them out of your OS and boot it from a floppy. You could also remove (or disconnect) the hard drive from your test machine.

Of course, if you test on real hardware, you'll also need a way to measure CPU usage.

[iansjack]

Note that VirtualBox is not an emulator.

[onlyonemac]

Note that VirtualBox is not an emulator.

Whatever, you're just picking on words.

[iansjack]

My view is that the difference between an emulator and virtualization software is actually more than just a matter of words. Especially when the discussion is about CPU usage.

[mohammedisam]

That depends on the emulator, but as we've already mentioned Bochs will keep the host CPU busy while according to SpyderTL VirtualBox apparently lets the host CPU idle when the emulated CPU is idle.

In fact this was a great suggestion. I did try it on VirtualBox and indeed the CPU is idle when the idle task is running, using only 3-4% of the host CPU.

Define "disk drivers". If you mean floppy disk drivers, then there's no reason not to test on real hardware. If you mean hard disk drivers, then pull them out of your OS and boot it from a floppy. You could also remove (or disconnect) the hard drive from your test machine.

I am writing the virtual file system layer (reading/editing FAT tables, Ext2 dirs/files and so on) so I expect my kernel to mess the disk pretty well. But disconnecting the hard disk is a good thought.

Of course, if you test on real hardware, you'll also need a way to measure CPU usage.

Yep, I got what you and Brendan said before. That is indeed a wise move. I will be working on the clock and timer facilities soon.

Great info, thanks a lot

[iansjack]

That depends on the emulator, but as we've already mentioned Bochs will keep the host CPU busy while according to SpyderTL VirtualBox apparently lets the host CPU idle when the emulated CPU is idle.

In fact this was a great suggestion. I did try it on VirtualBox and indeed the CPU is idle when the idle task is running, using only 3-4% of the host CPU.

This is to be expected, because the CPU is not emulated in VirtualBox.

[Ch4ozz]

When I test my OS on VBox, VMWare and QEMU it never exceeds 3% CPU usage.
HLT works pretty fine I'd say

[DavidCooper]

What is the correct way to use the HLT instruction? If an interrupt occurs just before the HLT is acted on, your interrupt routine runs, then control is returned to where the code was running before the interrupt and it will run straight into the HLT, stopping without any further action being able to take place until there's another interrupt, and yet there may be a lot of work needing to be done in a hurry as a result of the previous interrupt. I can't see any way round this other than using self-modifying code to replace the HLT instruction with a NOP (from every interrupt routine), and then the NOP would have to replaced with HLT afterwards, or every interrupt routine could check the return address and modify it to take it past the HLT if it happens to be in the stretch of code running towards the HLT. What should you actually do then - just let it halt and rely on timer interrupts to wake it up at some point to get the vital work done?

[SpyderTL]

What is the correct way to use the HLT instruction?

The "correct" way, in my opinion, would be to let the OS call the HLT instruction, and only when there is no work to be done. The applications (threads) should call a "yield()" or "sleep()" kernel function that will notify the OS that the current thread is out of work to do, or is waiting on some specific event to happen. Then the OS can decide to swap to a different thread, if there are any threads that have work to do, or it can call the HLT instruction.

But the key is, applications should not call the HLT instruction, only the OS, and only when all threads are "idle".

What should you actually do then - just let it halt and rely on timer interrupts to wake it up at some point to get the vital work done?

Any interrupt will wake up the CPU, not just the timer. So if there really is no work to do, and the OS calls the HLT instruction, it will wake back up and call the appropriate interrupt handler if the timer elapses, or if a keyboard key is pressed, or if the mouse is moved, or if a network packet is received (or sent), or if a USB device is plugged in, and so on. Then, the instruction immediately after the HLT instruction will be executed. You will actually have to call the HLT instruction again, if you want the CPU to go back to sleep.

So, you don't have to worry about the CPU being "asleep" if there is actually work to do. An interrupt will always wake it back up.