Date: Mon, 25 Nov 2002 16:26:16 -0800 From: Luigi Rizzo <rizzo@icir.org> To: hackers@freebsd.org Subject: out-of-order execution and code profiling Message-ID: <20021125162615.A52619@xorpc.icir.org>
next in thread | raw e-mail | index | archive | help
Hi,
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 ?
cheers
luigi
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021125162615.A52619>