Messages in this thread | | | Date | Mon, 13 Dec 2004 12:28:53 +0100 | From | Andrea Arcangeli <> | Subject | Re: dynamic-hz |
| |
On Sun, Dec 12, 2004 at 06:50:30PM -0700, Zwane Mwaikambo wrote: > Well most x86(64) these days have local APICs and that provides a > relatively inexpensive one shot timer mode.
I doubt a one shot is appropriate. The irq latency is variable and we won't be able to atomically read tsc and rearm the one-shot timer. The intemediate error will propagate over time.
You were the one making the case of the NMI, the NMI will screw completely any attempt of rearming the TSC accurately (though I don't mind too much, like for the sti; hlt, since NMI is pratically impossible to trigger in production, if a NMI is fired we've more troubles than the 1/HZ latency on a pending wakeup or on the system time taking the tangent ;)
Note that what we would have to implement to use a one-shot timer for timekeeping, it's very similar to the algorithm we already have if the timer irq get lost because we lost one tick.
My USB modem generates a flood of irq latency >1msec (I tried to track it down where it comes from but I failed, it seems not a cli but just the usb_uhci interrup taking 3msec to execute, and the timer irq failing to execute nested, perhaps I could fix it by forcing irq priorities by hand), so the tick-loss-adjustment always trigger on my firewall, and it costantly goes in the future of a minute per hour or so. I had to hack the code myself to reduce a bit the tsc value and now it's almost in time, randomly deviating in future and past (note the deviation with the mainline code is too huge that ntpd has no way to fix it, and it's like having ntp turned off). It's too bad I couldn't yet find any bug in the tick-loss adjustment algorithm yet.
In the current tick-loss adjustment case it's the delay_at_last_interrupt and rdtscl that can't be atomic and that will force an error on us. In the one shot case it's the read of the tsc and the rearming that cannot be atomic and it will force an error on the system time.
Now perhaps the error is small enough with a fast programming chip like the apic, but the awful results I've got out of the lost-tick adjustment scares me a bit to depend on a variable error to make the system time accurate.
Even with the PIT, HZ=100/1000 are two numbers were we can get decent accuracy, there are probably other frequencies where the accuracy is less.
(btw, my firewall systemtime will get fixed too by dyanmic-hz HZ=100, it's pure waste to keep my firewall at HZ=1000 even if I didn't have constant irq-latency of 3/4msec [measured with rdtsc], though I didn't mention this yet because dynamic-hz in my firewall case would be a pure band-aid, even fixing the tick-lost adjustment would be a band-aid, the only thing to fix is the usb irq that runs for 3/4msec without returning). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |