Re: dynamic-hz

[Andrea Arcangeli]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/