Call for performance evaluation: net.isr.direct (fwd)

[Bruce Evans]

On Fri, 14 Oct 2005, Poul-Henning Kamp wrote:

> In message <17231.43525.446450.161986 at grasshopper.cs.duke.edu>, Andrew Gallatin
> writes:
>> What if somebody were to port the linux TSC syncing code, and use it
>> to decide whether or not set kern.timecounter.smp_tsc=1?  Would you
>> object to that?
>
> Yes, I would object to that.
>
> Even to this day new CPU chips come out where TSC has flaws that
> prevent it from being used as timecounter, and we do not have (NDA)
> access to the data that would allow us to build a list of safe
> hardware.

Um, I have already pointed out that NDAs are not necessary.

They (and staic lists) are also not sufficient.  E.g., on my A7V-266E
system (AXP on KT266A motherboard), the following breaks the TSC for
timecounting:

 	# Athlon idle hack for my KT266A.
 	pciconf -w -b pci0:0:0 0x92 0xf9	# 79 -> f9
 	pciconf -w -b pci0:0:0 0x95 0x1a	# 18 -> 1a

Enough is freely disclosed, and the hardware is perfectly safe, but
only if it configured without the (idle == really idle) setting which
is set by the above hack but not by the BIOS.  This setting reduces
the temperature of a mostly-idle AXP system by about 10 degrees C.
IIRC, the (idle == really idle) feature is entirely in the CPU and the
hack just changes the state of the pins that control this feature.
The breakage is much the same for 2 different generations of AXPs (a
'1600 and a '2200) -- it causes jumps in the milliseconds per second
range where without it there is only temperature-related drift in the
nanoseconds per second range.  I suspect all AXPs have this feature
so they all have a potentially-broken TSC timecounter.

Bruce