Messages in this thread Patch in this message | | | Date | Tue, 30 Mar 1999 15:32:33 +0200 (CEST) | From | Andrea Arcangeli <> | Subject | Re: [patch] __volatile__ needed in get_cycles()? |
| |
On Tue, 30 Mar 1999, Tigran Aivazian wrote:
>Hi Andrea, > >On Mon, 29 Mar 1999, Andrea Arcangeli wrote: > >> +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; >> +} >> + >Yes, I like the above, I did not know you can do > >__asm__ __volatile__("": :); > >to stop compiler from re-ordering things (because I never looked at wmb() >macro). (and I like the "pseudo-smiley" at the end :).
Infact you can't do that (thanks to MikeG for make me noticing this) ;). It's been my fault. While I thought that the C compiler shouldn't look throught the contents of the asm (""), it seems he is optimizing it away (too much smart ;) even if it's an "nop" and not a "".
Note that instead barrier():
__asm__ __volatile__("": : : "memory");
make sense.
Note also that using __volatile__ in get_cycles() (as in 2.2.5) will automagically fix the __asm__ __volatile__("": :); noop-problem.
>Also, certainly bus-locked movl (or addl) is cheaper than cpuid (cpuid is >messy and trashes your registers).
Yes.
>I assume that if something is inline but is never referenced gcc will >simply ignore it so, whoever wants to profile something he will just put >it there manually. Almost (ignoring compile-time) zero overhead.
Of course ;).
So after more appropriate testing done by MikeG here it is a my new patch:
Index: include/asm-i386/timex.h =================================================================== RCS file: /var/cvs/linux/include/asm-i386/timex.h,v retrieving revision 1.1.1.2 retrieving revision 1.1.2.4 diff -u -r1.1.1.2 -r1.1.2.4 --- timex.h 1999/03/29 21:39:41 1.1.1.2 +++ linux/include/asm-i386/timex.h 1999/03/29 22:14:01 1.1.2.4 @@ -44,4 +44,10 @@ #endif } +extern cycles_t inline get_cycles_ordered(void) +{ + __asm__ __volatile__ ("lock; addl $0,0(%%esp)": :); + return get_cycles(); +} + #endif
Then we should discover if a post-rdtsc is really needed. My guess is that the CPU is not so smart to start executing out of order after a flush but who knows... I'll have a look at the specs hoping to find something...
Thanks again to Mike Galbraith for the feedback and the testcase.
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/
| |