On Mon, 25 Nov 2002, Luigi Rizzo wrote:
I just got hit by a peculiar problem related to out-of-order
execution of instructions.
I was doing some low-level timing measurements using the rdtsc()
around selected pieces of code (the rdtsc() is included in
the TSTMP() functions that are in RELENG_4, source is in
sys/i386/isa/clock.c), as follows:
TSTMP(3, ifp-if_unit, 1, 0);
tmp = CSR_READ_1(sc, FXP_CSR_SCB_STATACK);
TSTMP(3, ifp-if_unit, 2, 0);
TSTMP(3, ifp-if_unit, 3, 0);
CSR_READ_1() goes to do a volatile read on memory across a 33MHz
PCI bus, so it should take a very minimum of 100ns, plus arbitration
and bridge crossing and whatnot. To my surprise, on a 750MHz Athlon
box, the delta between the first two timestamps turned out to be
in the order of 39 clock cycles, whereas the delta between 2 and 3
is the 270-300 cycles range.
The only explaination i can find is that the rdtsc() within TSTMP()
is executed out of order.
I wonder, is there on the high-end i386 processors any 'barrier'
instruction of some kind that enforces in-order execution of some
piece of code ?
The Intel processor manual has an explicit example for this and recommends
you use cpuid as a serializing instruction before the call to rdtsc.
Basically you call cpuid + rdtsc a bunch of times to calibrate its average
latency. Then do your run with cpuid + rdtsc to get the beginning and end
clockstamp, subtract the two plus the latency you calculated above. This
gives a good value for the cycles in your routine.
Other factors like acpi can affect rdtsc so beware of this.
-Nate
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
