All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
To: David Miller <davem@davemloft.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: sparc64: Optimized immediate value implementation build error
Date: Tue, 14 Oct 2008 12:08:48 -0400	[thread overview]
Message-ID: <20081014160848.GA20740@Krystal> (raw)
In-Reply-To: <20081014.021506.18668456.davem@davemloft.net>

* David Miller (davem@davemloft.net) wrote:
> From: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
> Date: Tue, 14 Oct 2008 00:47:58 -0400
> 
> > * David Miller (davem@davemloft.net) wrote:
> > > I'll pull in 0.40 next.
> > 
> > I'm looking forward to hear about the results. Thanks !
> 
> It builds, and I made sure that USE_IMMEDIATE does get defined
> by the makefile changes you made.
> 
> 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 ?

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.


> 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.

Mathieu

> Signed-off-by: David S. Miller <davem@davemloft.net>
> 
> diff --git a/arch/sparc/include/asm/unistd_32.h b/arch/sparc/include/asm/unistd_32.h
> index 648643a..ef924f4 100644
> --- a/arch/sparc/include/asm/unistd_32.h
> +++ b/arch/sparc/include/asm/unistd_32.h
> @@ -338,8 +338,10 @@
>  #define __NR_dup3		320
>  #define __NR_pipe2		321
>  #define __NR_inotify_init1	322
> +#define __NR_marker		323
> +#define __NR_trace		324
>  
> -#define NR_SYSCALLS		323
> +#define NR_SYSCALLS		325
>  
>  /* Sparc 32-bit only has the "setresuid32", "getresuid32" variants,
>   * it never had the plain ones and there is no value to adding those
> diff --git a/arch/sparc/include/asm/unistd_64.h b/arch/sparc/include/asm/unistd_64.h
> index c5cc0e0..bd830d8 100644
> --- a/arch/sparc/include/asm/unistd_64.h
> +++ b/arch/sparc/include/asm/unistd_64.h
> @@ -340,8 +340,10 @@
>  #define __NR_dup3		320
>  #define __NR_pipe2		321
>  #define __NR_inotify_init1	322
> +#define __NR_marker		323
> +#define __NR_trace		324
>  
> -#define NR_SYSCALLS		323
> +#define NR_SYSCALLS		325
>  
>  #ifdef __KERNEL__
>  #define __ARCH_WANT_IPC_PARSE_VERSION
> diff --git a/arch/sparc/kernel/systbls.S b/arch/sparc/kernel/systbls.S
> index e1b9233..0a1dd3d 100644
> --- a/arch/sparc/kernel/systbls.S
> +++ b/arch/sparc/kernel/systbls.S
> @@ -81,4 +81,4 @@ sys_call_table:
>  /*305*/	.long sys_set_mempolicy, sys_kexec_load, sys_move_pages, sys_getcpu, sys_epoll_pwait
>  /*310*/	.long sys_utimensat, sys_signalfd, sys_timerfd_create, sys_eventfd, sys_fallocate
>  /*315*/	.long sys_timerfd_settime, sys_timerfd_gettime, sys_signalfd4, sys_eventfd2, sys_epoll_create1
> -/*320*/	.long sys_dup3, sys_pipe2, sys_inotify_init1
> +/*320*/	.long sys_dup3, sys_pipe2, sys_inotify_init1, sys_marker, sys_trace
> diff --git a/arch/sparc64/kernel/systbls.S b/arch/sparc64/kernel/systbls.S
> index 0fdbf3b..0257912 100644
> --- a/arch/sparc64/kernel/systbls.S
> +++ b/arch/sparc64/kernel/systbls.S
> @@ -82,7 +82,7 @@ sys_call_table32:
>  	.word compat_sys_set_mempolicy, compat_sys_kexec_load, compat_sys_move_pages, sys_getcpu, compat_sys_epoll_pwait
>  /*310*/	.word compat_sys_utimensat, compat_sys_signalfd, sys_timerfd_create, sys_eventfd, compat_sys_fallocate
>  	.word compat_sys_timerfd_settime, compat_sys_timerfd_gettime, compat_sys_signalfd4, sys_eventfd2, sys_epoll_create1
> -/*320*/	.word sys_dup3, sys_pipe2, sys_inotify_init1
> +/*320*/	.word sys_dup3, sys_pipe2, sys_inotify_init1, sys_marker, sys_trace
>  
>  #endif /* CONFIG_COMPAT */
>  
> @@ -156,4 +156,4 @@ sys_call_table:
>  	.word sys_set_mempolicy, sys_kexec_load, sys_move_pages, sys_getcpu, sys_epoll_pwait
>  /*310*/	.word sys_utimensat, sys_signalfd, sys_timerfd_create, sys_eventfd, sys_fallocate
>  	.word sys_timerfd_settime, sys_timerfd_gettime, sys_signalfd4, sys_eventfd2, sys_epoll_create1
> -/*320*/	.word sys_dup3, sys_pipe2, sys_inotify_init1
> +/*320*/	.word sys_dup3, sys_pipe2, sys_inotify_init1, sys_marker, sys_trace
> 

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

  reply	other threads:[~2008-10-14 16:08 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-03 20:10 sparc64: Optimized immediate value implementation build error Mathieu Desnoyers
2008-10-13  8:15 ` David Miller
2008-10-13 23:37   ` Mathieu Desnoyers
2008-10-14  1:31     ` David Miller
2008-10-14  2:17       ` Mathieu Desnoyers
2008-10-14  2:31         ` David Miller
2008-10-14  4:47           ` Mathieu Desnoyers
2008-10-14  9:15             ` David Miller
2008-10-14 16:08               ` Mathieu Desnoyers [this message]
2008-10-14 19:02                 ` David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081014160848.GA20740@Krystal \
    --to=mathieu.desnoyers@polymtl.ca \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.