>On Mon, 29 Mar 1999, Richard Henderson wrote:
>> Adding the volatile makes the asm act as a scheduling barrier.
>
>Yes, but only on P5 (below P5 there is no rdtsc at all) architecture. Due
>to the speculative execution of the P6 and above you will also need a
>serializing instruction (e.g. cpuid) to make it a true "barrier".
Index: timex.h
===================================================================
RCS file: /var/cvs/linux/include/asm-i386/timex.h,v
retrieving revision 1.1.2.1
diff -u -r1.1.2.1 timex.h
--- timex.h 1999/01/18 01:33:32 1.1.2.1
+++ linux/include/asm-i386/timex.h 1999/03/29 19:25:46
@@ -44,4 +44,16 @@
#endif
}
+extern cycles_t inline get_cycles_ordered(void)
+{
+ /* I know I should not use `register' but I can't resist ;). -Andrea */
+ register cycles_t foo;
+
+ __asm__ __volatile__ ("lock; addl $0,0(%%esp)": :);
+ foo = get_cycles();
+ __asm__ __volatile__("": :);
+
+ return foo;
+}
+
#endif
This my new inline function should assure both asm ordering and CPU
ordering, but as just said, get_cycles() is just fine and this one is a
different issue that so far is been handled by hand (also because usually
you need this trick only for profiling and not for real code).
The cycles added by the addl %esp should be not a problem because usually
with profiling you are interested in which is the faster code and not
which is the exact measure of the time.
Note also the the original mb() was also flushing the register set because
such move to memory was needed for SMP safe operation, while instead I
only assured the ordering of the instruction at the CPU level and the
ordering of the asm. I hope I have not missed something ;). A safer
version would be
mb()
ret = get_cycles()
barrier()
(and it would have worked also in include/linux/timex.h) but it looked to
me an overhead that could also lead to not relialable profiling results.
Comments?
Andrea Arcangeli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/