Re: sparc64: Optimized immediate value implementation build error

[David Miller <davem@davemloft.net>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: Text/Plain; charset=utf-8, Size: 2352 bytes --]

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 :)
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥