idle method in commericial OS

[MonkeyMan]

I hear many of the OS devlopers use infinite HLT for idle process. Yet this method still consumes 100% processor. What I'm curious about is how does windows/linux manage to keep processor level at 0% during idling. Surely they're not doing infinte HLT. Is it complex to keep a processor at 0% during idle stage ?!


thanks

[Pype.Clicker]

what do make you think a thing like

Code: Select all

idle:
    hlt
    jmp idle

consumes 100% of the processor time ?
'hlt' actually freezes (hence the mnemonic: HaLT) the cpu until an interrupt is taken, thus yes, the processor will remain in the context of the idle process, but executing no instruction but the interrupt handlers ... And an interrupt is always taken immediately.

the OS will simply decide that when the current process is idle_pid when the timer interrupt occur, the processor was free ...

As the idle process usually has the lowest possible priority, it effectively counts the amount of time when the system "has nothing to do" while allowing the cpu to do nothing for this time.

Have you a better definition of 'idle' to offer ?

[BI lazy]

*ggg*

maybe that lad 's deduced his assumption by looking at the following:

take the process manager of windows and look at the list of currently present processes. At top of it most of the time the processor seems to spin around the idle process/task.

This can be falsified easily: just look at the processor-usage ("prozessorlast" - how to translate it to english? - processor burden?) - it's just one tab away, and see where the curve runs: nearly 0 % of processor usage.

Simply put: just that the ressource "processor" is assigned 'bout 99 % to the idle process/task doesn't permit the assumption, that actually 99 % of processor power are used ... simply hlt the processor after some book keeping and save energy.

to put it short 'n simply: pype is right.

[MonkeyMan]

I have:

Code: Select all

while(1)  asm("hlt");

I run my OS in Bochs the processor usage remains at 100%. I just realized the same OS doesnt run at 100% in VMware...
hmmm.....

[Solar]

"prozessorlast" - how to translate it to english?

Load. (CPU load, processor load)

I run my OS in Bochs the processor usage remains at 100%.

That's a quite usual behaviour for CPU emulators. (UAE also eats CPU load like mad even when the emulated tasks are all idle.)

[Pype.Clicker]

I run my OS in Bochs the processor usage remains at 100%.
hmmm.....

This should no longer be the case with the latest release of BOCHS (2.0.2). However, keep in mind that a virtual machine like bochs also need to emulate chips other than the CPU. It can also keep the real CPU load high despite of your HaLTs if the interrupts are frequent or heavy to process.

With Clicker on bochs 2.0.2, the CPU load of my 1GHz cpu remains at 100% until i activate the idle thread. Once this is done, i drop at about 15% (but certainly not 0%), and this is because i keep the timer interrupt very very slow (18.2 Hz) on virtual CPUs.

[MonkeyMan]

This should no longer be the case with the latest release of BOCHS (2.0.2)

I do have that version installed in Windows. Also the way I setup my timer should be firing approx. once per second. When I test the OS on a real pc and VMware I get the expected bahavior of once per sec. but the instant I run it on bochs it seems its at atleast 10-20 per sec.

Code: Select all

if (ticks > 100) {
   kprintf("*\t");
    ticks = 0;
}

is what I use and bochs fills up the screen incredibly fast! Maybe I should check bochs for the latest udpates or something...

[Pype.Clicker]

my bochs is on linux. And Bochs is known for being very fuzzy on timing (it may tick faster than you required). The virtual PC bochs offer is not realtime.

[bkilgore]

And Bochs is known for being very fuzzy on timing (it may tick faster than you required). The virtual PC bochs offer is not realtime.

From what I understand about bochs, it's timing is "exact" in that everything inside the virtual PC is emulated exactly, but this doesn't necessarily correspond to the real world (except for in a proportional manner).

When you set your IPS value in the configuration file, you tell it how much the clock should be updated for each instruction (1/IPS). So if IPS = 100,000, then every instruction should update the clock by 1/100000 second. This means that, for every firing of your interrupt, you can be guaranteed that 100000 instructions occured.

Because of this it's very deterministic (i.e., you can know that the *exact* same instructions will execute between any two given timer interrupts no matter how many times you run the program). However, because the instructions emulated vary in execution time, and because you can change the IPS value, there's nothing tieing the timer interrupt to real-world time.

It *is* possible to tweak the IPS value to make the interrupts coincide better with the real-world (values change based on CPU and are best achieved with trial and error), but this can make the emulated system run very slowly as bochs uses this value internally as well.

[Curufir]

Actually HLT isn't the last word in shutting down the processor. It's right that it isn't actually doing anything after this instruction so effective load is zero whilst the idle task is running, but from a power conservation point of view the idle thread question becomes a lot more complex on modern systems.

Here's a link for anyone interested in an overview:
http://grassomusic.de/english/amdk7.htm

[MonkeyMan]

It *is* possible to tweak the IPS value to make the interrupts coincide better with the real-world (values change based on CPU and are best achieved with trial and error), but this can make the emulated system run very slowly as bochs uses this value internally as well.

Actually there is no need to mess with IPS value. Just setting realtime to 1 works great!

In bxrc config file add:

Code: Select all

pit: realtime=1