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 ?
sched_clock() is meant to provide a clock good enough for scheduler
needs, which implies some rough edges in the way precise counting can be
capped to a max value so it does not go over the predicted cycle count
within the current jiffies period and stuff like that. Given this
latency_test code mainly aims at checking the worse-case latencies
generated by psrwlock, I prefer to use rock-solid time bases (e.g.
synchronized cycle counter) and do just disable the whole code if the
architecture does not provide a precise enough counter or a counter
which requires any kind of locking (I don't want to change the
measurements of timings of this new locking mechanism because of
seq_lock timings).
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 ? If not, just defining an empty get_cycles_barrier() macro should
be good enough. As a comparison, get_cycles() on x86_32 issues rdtsc
which is guaranteed to be a synchronizing instruction, so
rdtsc_barrier() is defined as empty.
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 ?
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.
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.
Mathieu
--
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
--
