Re: [PATCH resend] Perf-tool/MIPS: support cross compiling of tools/perf for MIPS

[Deng-Cheng Zhu <dengcheng.zhu@gmail.com>]

Thanks guys. So let's turn the patch into the following?

Signed-off-by: Deng-Cheng Zhu<dengcheng.zhu@gmail.com>
---
 tools/perf/perf.h |   14 ++++++++++++++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/tools/perf/perf.h b/tools/perf/perf.h
index 6fb379b..cd05284 100644
--- a/tools/perf/perf.h
+++ b/tools/perf/perf.h
@@ -73,6 +73,20 @@
 #define cpu_relax()    asm volatile("":::"memory")
 #endif

+#ifdef __mips__
+#include "../../arch/mips/include/asm/unistd.h"
+#define rmb()          asm volatile(                                   \
+                               ".set      push\n\t"                  \
+                               ".set      noreorder\n\t"                     \
+                               ".set      mips2\n\t"                 \
+                               "sync\n\t"                            \
+                               ".set      pop"                               \
+                               : /* no output */                       \
+                               : /* no input */                        \
+                               : "memory")
+#define cpu_relax()    asm volatile("" ::: "memory")
+#endif
+
 #include<time.h>
 #include<unistd.h>
 #include<sys/types.h>


On 2010-10-2 9:59, Ralf Baechle wrote:
> On Fri, Oct 01, 2010 at 02:45:17PM -0700, David Daney wrote:
>
> > In user space the rmb() must expand to a SYNC instruction.  I am not
> > sure what your version in the patch is doing with all those NOPs.  That
> > is not guaranteed to do anything.
> That's a rather old version of the kernel rmb macro I think.  The NOPs
> where there to enforce ordering of a mix of cached and uncached accesses
> on the R4400 (not R4000) where according to my reading the manual leaves
> it a bit unclear if a SYNC is sufficient or if the pipeline needs to be
> drained in addition.  See version 2 of the R4000/R4400 User's Manual.
>
> > The instruction set specifications say that SYNC orders all loads and
> > stores.  This is a heaver operation than rmb() demands, but is the only
> > universally available instruction that imposes ordering.
> >
> > For processors that do not support SYNC, the kernel will emulate it, so
> > it is safe to use in userspace.  I wouldn't worry about emulation
> > overhead though, because processors that lack SYNC probably also lack
> > performance counters, so are not as interesting from a perf-tool point
> > of view.
> Yes, just use SYNC.  SYNC-less processors would only be R2000/R3000
> processors and a few other oddball processors which for performance
> optimization are totally uninteresting since years.
>
>    Ralf