lkml.org 
[lkml]   [2008]   [Oct]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: sparc64: Optimized immediate value implementation build error
From
From: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Date: Tue, 14 Oct 2008 12:08:48 -0400

> * David Miller (davem@davemloft.net) wrote:
> > On the other hand, CONFIG_PSRWLOCK_LATENCY_TEST fails to build:
> >
> > CC lib/psrwlock-latency-trace.o
> > lib/psrwlock-latency-trace.c: In function ‘calibrate_get_cycles’:
> > lib/psrwlock-latency-trace.c:60: error: implicit declaration of function ‘rdtsc_barrier’
> >
> > You could use sched_clock() or similar, we do have portable
> > interfaces by which to do these things. And if we don't
> > have something fitting exactly what is needed here, add it :-)
> >
>
> I think the %tick register we get with get_cycles() on sparc64 is what
> is needed. Hopefully it's synchronized across CPUs on SMP systems ?

Yes, it is synchronized.

> On x86_64, rdtsc_barrier() issues a synchronizing instruction (cpuid)
> which serializes the instructions executed on the CPU so we do not
> execute rdtsc speculatively. Is reading %tick synchronized on sparc64 or
> not ?

It is synchronized on sparc64.

> Is there a similar %tick register on sparc32 ? I've read somewhere it's
> new to sparc v8. (http://cr.yp.to/hardware/sparc.html) So I guess we
> should simply disable this psrwlock latency tracer on SPARC32 ?

Not really. There is only the time keeping device out in I/O space
which is very expensive to access.

This is why we don't have a sched_clock() implementation on sparc32.

> Probably that the best way to deal with this is to create a
>
> (generic code)
> HAVE_GET_CYCLES
> def_bool n
>
> (sparc, x86, powerpc... Kconfig)
> config SPARC64/X86/POWERPC
> select HAVE_GET_CYCLES
>
> And we can make CONFIG_PSRWLOCK_LATENCY_TEST depend on HAVE_GET_CYCLES.

Yes, something like that.

> > Also:
> >
> > <stdin>:1421:2: warning: #warning syscall marker not implemented
> > <stdin>:1425:2: warning: #warning syscall trace not implemented
> >
> > which should be fixed by the following patch:
> >
> > sparc: Add sys_trace() and sys_marker() syscall table entries.
> >
>
> Thanks, I'll merge it :) I don't expect the userspace tracing to be in
> its final form, but it's good to add such support.

I think so too :)
\
 
 \ /
  Last update: 2008-10-14 21:05    [W:0.032 / U:0.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site