IRC channel logs

<damo22>youpi: do you have any ideas how i should proceed to figure out why smp is so slow?

<damo22>its so slow i cannot boot a working system to check performance

<damo22>one idea i have is the lapic timer might be miscalibrated

<damo22>but when i speed it up, 10 seconds of delay becomes less than a second

<damo22>timers*

<damo22>with -smp 8 it uses 200% cpu load on the host while trying to boot

<damo22>but its mostly idle

<damo22>the scheduler could be starving the cpus

<damo22>while one core sits in a loop doing something boring

<damo22>its now using 110%

<damo22>stuck at Hurd server bootstrap: ext2fs[part:2: device:wd0] exec startup proc auth.

<Pellescours>damo22: i don't know if you noticed but smp with 1 cpu, the time is too fast. I launched htop and the time is like twice fast

<damo22>Pellescours: thats interesting

<damo22>if there are too many timer interrupts due to time ticking too fast that could explain slowness of system

<damo22>s/time ticking too fast/timer expiring too early/

<damo22>ie, system could be too busy servicing timer interrupts to process anything else

<damo22>uptime goes at 3x faster

<damo22>4x

<damo22>sorry

<Pellescours>and this may explain some messages in rump about lost interrupt.

<damo22>i need help to calibrate the timer

<damo22>i tried a simple calibrated_ticks adjustment *4

<damo22>it works almost correctly but i dont know why

<damo22>if you do watch -n1 w

<damo22>hmm it could be 16x

<damo22>which would coincide with the timer divisor

<Pellescours> https://wiki.osdev.org/APIC_timer

<damo22>im using LAPIC_TIMER_DIVIDE_16

<damo22>does that mean i need to *16 the ticks value?

<damo22>Timer DCR=0x3 (divide by 16) initial_count = 4500800

<damo22>is that a reasonable count?

<Pellescours>no idea

<damo22>16 is too slow now

<Pellescours>The APIC timer can be set to make a tick (decrease counter) at a given frequency, which is called "divide value". This means you have to multiply APIC timer counter ticks by this divide value to get the true CPU bus frequency.

<damo22>im not interested in the cpu bus frequency, i want to make the counter expire in 10ms

<damo22>so what i did, i know the PIT timer has a fixed frequency

<Pellescours>at the bottom of the osdev page there is a code snippet, I don't kniw if it helps. i don't kniw the gnumach code enough

<damo22>so i set the APIC timer to count down from maximum, and made the pit delay 10ms, then stopped the apic timer and counted the ticks

<damo22>but it doesnt seem to be accurate

<Pellescours>why do we multiply the calibrated timer value we get from pit by hz?

<damo22>yeah i dont know

<damo22>i am going to remove that and make the timer divider to be 2

<damo22>1 doesnt work on bochs

<damo22>it should sleep for 1 second and then divide by hz?

<damo22>to be more accurate

<damo22>or even 100ms

<damo22>im finding that the calibrated ticks is way too small

<damo22>when i measure it with pit

<damo22>with a timer divisor of 2, it should be counting down at half the cpu frequency

<damo22>cpu bus freq

<damo22>if the cpu bus frequency is 800Mhz, then divide=2 means timer counts down at 400,000,000 / second

<damo22>how am i getting calibrated ticks = 25000

<Pellescours>is the pit sleep working correctly? I think yes

<damo22>problem is i dont know the cpu bus frequency

<damo22>im just guessing

<Pellescours>qemu is not able to tell you?

<damo22>cant find it

<Pellescours>is the pit correctly init when you use it to calibrate apic timer?

<damo22>um

<damo22>pit_prepare_sleep()

<damo22>sets up the amount to wait

<damo22>then pit_sleep actually waits

<Pellescours>And the code in clkstart ? It’s never called with apic, so we never configure his mode

<damo22>clkstart is to make it periodically set up interrupts for timer

<Pellescours>so it’s not necessary here?

<damo22>i dont think so?

<damo22>AHH CLKNUM is already divided by HZ

<damo22>hmm maybe not

<damo22>maybe the PIT_C2 counter has the wrong divider

<damo22>the pit is not working correctly

<damo22>i made it wait 10 seconds by doing a loop of 1000x 10ms delays and it ran in a split second

<damo22>one shot PIT mode seems broken

<damo22>it doesnt delay long enough

IRC channel logs

2023-02-25.log