IRC channel logs


back to list of 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>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
<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
<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>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