>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/