Re: b_delay = 100% CPU

[Ian Seyler]

It is because the os_delay function uses polling to check the value of the clock counter. Polling will cause a CPU to execute at 100% load. This is the expected behavior of the function but is not really ideal.

I will experiment with adding a 'hlt' opcode to the os_delay function which would resolve this issue. HLT puts the CPU into a sleep mode until an interrupt is triggered.

-Ian

On Wednesday, April 11, 2012 9:07:48 AM UTC-4, håvard ostnes wrote:

Hi

I have a simple program which utilize 100% CPU when it uses the
b_delay() function:

#include "libBareMetal.h"

int main(void)
{
  b_print_string("testing\n");
  b_delay(80);
 return 0;
}

After printing "testing" the CPU sleeps for 10 seconds, but utilize
100% CPU.

Any idea of why?

[Ian Seyler]

This is a 2-line fix.

In misc.asm in the os_delay function:

os_delay_loop:

hlt

cmp qword [os_ClockCounter], rax ; Compare it against our end time

jle os_delay_loop ; Loop if RAX is still lower

The loop is modified to 'hlt' until an interrupt is received.

In interrupt.asm in the rtc function:

rtc_end:

mov al, 0x0C ; Select RTC register C

out 0x70, al ; Port 0x70 is the RTC index, and 0x71 is the RTC data

in al, 0x71 ; Read the value in register C

mov rsi, [os_LocalAPICAddress] ; Acknowledge the IRQ on APIC

xor eax, eax

mov dword [rsi+0xB0], eax

call os_smp_wakeup_all ; A terrible hack

We add a call to os_smp_wakeup_all to broadcast whenever the RTC interrupt fires. This is not ideal as it wakes up all CPU cores instead of just the one that is waiting. This is the same way that the keyboard interrupt is handled at the moment.

I tried the changes and it removes the 100% CPU load when os_delay is called.

-Ian

On Monday, April 16, 2012 3:45:11 AM UTC-4, håvard ostnes wrote:

Ok :) Thank you so much for the reply.

Good luck, and I hope this will be updated soon ;)