Messages in this thread Patch in this message | | | Date | Mon, 29 Mar 1999 21:30:50 +0200 (CEST) | From | Andrea Arcangeli <> | Subject | Re: [patch] __volatile__ needed in get_cycles()? |
| |
On Mon, 29 Mar 1999, Tigran Aivazian wrote:
>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/
| |