Messages in this thread | | | Date | Tue, 14 Oct 2008 12:02:15 -0700 (PDT) | Subject | Re: sparc64: Optimized immediate value implementation build error | From | David Miller <> |
| |
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 :)
| |