linux-arch.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hans-Christian Egtvedt <egtvedt@samfundet.no>
To: Peter Zijlstra <peterz@infradead.org>
Cc: linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org,
	torvalds@linux-foundation.org, akpm@linux-foundation.org,
	mingo@kernel.org, will.deacon@arm.com,
	paulmck@linux.vnet.ibm.com,
	Haavard Skinnemoen <hskinnemoen@gmail.com>
Subject: Re: [PATCH 06/20] arch,avr32: Fold atomic_ops
Date: Fri, 9 May 2014 20:32:41 +0200	[thread overview]
Message-ID: <20140509183241.GA4491@samfundet.no> (raw)
In-Reply-To: <20140508135852.049922584@infradead.org>

Around Thu 08 May 2014 15:58:46 +0200 or thereabout, Peter Zijlstra wrote:
> Many of the atomic op implementations are the same except for one
> instruction; fold the lot into a few CPP macros and reduce LoC.

The add and sub atomic operations are not 100% the same. Sub has more
constraints on the integer size than add. Sub only takes a signed 21-bit
integer, while add can do 32-bit additions IIRC correctly the instructions
for AVR32.

This is why you see in atomic_sub_return() that i is typed as "rKs21", while
in atomic_add_return, i is typed "r".

Your change limits both atomic operations to work only on signed 21-bit
integers.

> This also prepares for easy addition of new ops.
> 
> Requires the asm_op because of eor.
> 
> Cc: Haavard Skinnemoen <hskinnemoen@gmail.com>
> Cc: Hans-Christian Egtvedt <egtvedt@samfundet.no>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Signed-off-by: Peter Zijlstra <peterz@infradead.org>
> ---
>  arch/avr32/include/asm/atomic.h |   96 ++++++++++++++++++----------------------
>  1 file changed, 44 insertions(+), 52 deletions(-)
> 
> --- a/arch/avr32/include/asm/atomic.h
> +++ b/arch/avr32/include/asm/atomic.h
> @@ -22,58 +22,52 @@
>  #define atomic_read(v)		(*(volatile int *)&(v)->counter)
>  #define atomic_set(v, i)	(((v)->counter) = i)
>  
> -/*
> - * atomic_sub_return - subtract the atomic variable
> - * @i: integer value to subtract
> - * @v: pointer of type atomic_t
> - *
> - * Atomically subtracts @i from @v. Returns the resulting value.
> - */
> -static inline int atomic_sub_return(int i, atomic_t *v)
> -{
> -	int result;
> -
> -	asm volatile(
> -		"/* atomic_sub_return */\n"
> -		"1:	ssrf	5\n"
> -		"	ld.w	%0, %2\n"
> -		"	sub	%0, %3\n"
> -		"	stcond	%1, %0\n"
> -		"	brne	1b"
> -		: "=&r"(result), "=o"(v->counter)
> -		: "m"(v->counter), "rKs21"(i)
> -		: "cc");
> -
> -	return result;
> +#define ATOMIC_OP(op, asm_op)						\
> +static inline void atomic_##op(int i, atomic_t *v)			\
> +{									\
> +	int result;							\
> +									\
> +	asm volatile(							\
> +		"/* atomic_" #op " */\n"				\
> +		"1:	ssrf	5\n"					\
> +		"	ld.w	%0, %2\n"				\
> +		"	" #asm_op "	%0, %3\n"			\
> +		"	stcond	%1, %0\n"				\
> +		"	brne	1b"					\
> +		: "=&r"(result), "=o"(v->counter)			\
> +		: "m"(v->counter), "rKs21"(i)				\

All variable i integers are limited to signed 21-bit here.

> +		: "cc");						\
> +}									\
> +
> +#define ATOMIC_OP_RETURN(op, asm_op)					\
> +static inline int atomic_##op##_return(int i, atomic_t *v)		\
> +{									\
> +	int result;							\
> +									\
> +	asm volatile(							\
> +		"/* atomic_" #op "_return */\n"				\
> +		"1:	ssrf	5\n"					\
> +		"	ld.w	%0, %2\n"				\
> +		"	" #asm_op "	%0, %3\n"			\
> +		"	stcond	%1, %0\n"				\
> +		"	brne	1b"					\
> +		: "=&r"(result), "=o"(v->counter)			\
> +		: "m"(v->counter), "rKs21"(i)				\

Same here.

> +		: "cc");						\
> +									\
> +	return result;							\
>  }
>  
> -/*
> - * atomic_add_return - add integer to atomic variable
> - * @i: integer value to add
> - * @v: pointer of type atomic_t
> - *
> - * Atomically adds @i to @v. Returns the resulting value.
> - */
> -static inline int atomic_add_return(int i, atomic_t *v)
> -{
> -	int result;
> -
> -	if (__builtin_constant_p(i) && (i >= -1048575) && (i <= 1048576))
> -		result = atomic_sub_return(-i, v);

I do not recall why we did it like this any more, I would assume both sub and
add to be single cycle instructions.

> -	else
> -		asm volatile(
> -			"/* atomic_add_return */\n"
> -			"1:	ssrf	5\n"
> -			"	ld.w	%0, %1\n"
> -			"	add	%0, %3\n"
> -			"	stcond	%2, %0\n"
> -			"	brne	1b"
> -			: "=&r"(result), "=o"(v->counter)
> -			: "m"(v->counter), "r"(i)
> -			: "cc", "memory");
> -
> -	return result;
> -}
> +#define ATOMIC_OPS(op, asm_op)						\
> +	ATOMIC_OP(op, asm_op)						\
> +	ATOMIC_OP_RETURN(op, asm_op)
> +
> +ATOMIC_OPS(add, add)
> +ATOMIC_OPS(sub, sub)
> +
> +#undef ATOMIC_OPS
> +#undef ATOMIC_OP_RETURN
> +#undef ATOMIC_OP
>  
>  /*
>   * atomic_sub_unless - sub unless the number is a given value
> @@ -168,8 +162,6 @@ static inline int atomic_sub_if_positive
>  #define atomic_xchg(v, new)	(xchg(&((v)->counter), new))
>  #define atomic_cmpxchg(v, o, n)	(cmpxchg(&((v)->counter), (o), (n)))
>  
> -#define atomic_sub(i, v)	(void)atomic_sub_return(i, v)
> -#define atomic_add(i, v)	(void)atomic_add_return(i, v)
>  #define atomic_dec(v)		atomic_sub(1, (v))
>  #define atomic_inc(v)		atomic_add(1, (v))

I like the simplification, do you manage to preprocessor both instruction and
instruction argument limit?

-- 
Best regards,
Hans-Christian Egtvedt

  reply	other threads:[~2014-05-09 18:32 UTC|newest]

Thread overview: 75+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-08 13:58 [PATCH 00/20] arch atomic 'cleanup' Peter Zijlstra
2014-05-08 13:58 ` Peter Zijlstra
2014-05-08 13:58 ` [PATCH 01/20] x86: Kill atomic_or_long() Peter Zijlstra
2014-05-08 13:58   ` Peter Zijlstra
2014-05-08 13:58 ` [PATCH 02/20] arch,alpha: Fold atomic_ops Peter Zijlstra
2014-05-08 13:58   ` Peter Zijlstra
2014-05-08 13:58 ` [PATCH 03/20] arch,arc: " Peter Zijlstra
2014-05-08 13:58   ` Peter Zijlstra
2014-05-09  9:34   ` Vineet Gupta
2014-05-09 10:22     ` Peter Zijlstra
2014-05-08 13:58 ` [PATCH 04/20] arch,arm: " Peter Zijlstra
2014-05-08 13:58   ` Peter Zijlstra
2014-05-08 18:31   ` Will Deacon
2014-05-08 13:58 ` [PATCH 05/20] arch,arm64: " Peter Zijlstra
2014-05-08 13:58   ` Peter Zijlstra
2014-05-08 18:31   ` Will Deacon
2014-05-08 13:58 ` [PATCH 06/20] arch,avr32: " Peter Zijlstra
2014-05-09 18:32   ` Hans-Christian Egtvedt [this message]
2014-05-09 20:43     ` Peter Zijlstra
2014-05-09 20:51       ` Peter Zijlstra
2014-05-09 21:17         ` Peter Zijlstra
2014-05-13 20:40           ` Hans-Christian Egtvedt
2014-05-13 20:50             ` Peter Zijlstra
2014-05-14  7:43               ` Hans-Christian Egtvedt
2014-05-31 14:14             ` Peter Zijlstra
2014-06-06  6:25               ` Hans-Christian Egtvedt
2014-05-08 13:58 ` [PATCH 07/20] arch,cris: " Peter Zijlstra
2014-05-08 13:58   ` Peter Zijlstra
2014-05-08 15:12   ` Geert Uytterhoeven
2014-05-08 16:06     ` Peter Zijlstra
2014-05-08 17:34       ` David Miller
2014-05-08 18:17         ` Peter Zijlstra
2014-05-08 20:27           ` David Miller
2014-05-09  8:14           ` Jesper Nilsson
2014-05-08 13:58 ` [PATCH 08/20] arch,hexagon: " Peter Zijlstra
2014-05-08 13:58   ` Peter Zijlstra
2014-05-12 17:28   ` rkuo
2014-05-08 13:58 ` [PATCH 09/20] arch,ia64: " Peter Zijlstra
2014-05-08 13:58   ` Peter Zijlstra
2014-05-08 13:58 ` [PATCH 10/20] arch,m32r: " Peter Zijlstra
2014-05-08 13:58   ` Peter Zijlstra
2014-05-08 13:58 ` [PATCH 11/20] arch,m68k: " Peter Zijlstra
2014-05-09  9:08   ` Geert Uytterhoeven
2014-05-09  9:16     ` Peter Zijlstra
2014-05-09  9:16       ` Peter Zijlstra
2014-05-09  9:44       ` Geert Uytterhoeven
2014-05-08 13:58 ` [PATCH 12/20] arch,metag: " Peter Zijlstra
2014-05-08 13:58   ` Peter Zijlstra
2014-05-13 10:06   ` James Hogan
2014-05-13 10:06     ` James Hogan
2014-05-08 13:58 ` [PATCH 13/20] arch,mips: " Peter Zijlstra
2014-05-08 13:58   ` Peter Zijlstra
2014-05-08 13:58 ` [PATCH 14/20] arch,mn10300: " Peter Zijlstra
2014-05-08 13:58   ` Peter Zijlstra
2014-05-08 13:58 ` [PATCH 15/20] arch,parisc: " Peter Zijlstra
2014-05-08 13:58   ` Peter Zijlstra
2014-05-08 13:58 ` [PATCH 16/20] arch,powerpc: " Peter Zijlstra
2014-05-08 13:58   ` Peter Zijlstra
2014-05-08 13:58 ` [PATCH 17/20] arch,sh: " Peter Zijlstra
2014-05-08 13:58   ` Peter Zijlstra
2014-05-08 13:58 ` [PATCH 18/20] arch,sparc: " Peter Zijlstra
2014-05-08 13:58 ` [PATCH 19/20] arch,xtensa: " Peter Zijlstra
2014-05-08 13:59 ` [PATCH 20/20] arch: Rewrite generic atomic support Peter Zijlstra
2014-05-08 15:24   ` Sam Ravnborg
2014-05-08 18:26     ` Peter Zijlstra
2014-05-20 13:05 ` [PATCH 14/20] arch,mn10300: Fold atomic_ops David Howells
2014-05-20 13:16   ` Peter Zijlstra
2014-05-20 13:16     ` Peter Zijlstra
2014-09-24 16:54 ` [PATCH 00/20] arch atomic 'cleanup' Will Deacon
2014-09-24 16:54   ` Will Deacon
2014-09-24 18:06   ` Peter Zijlstra
2014-09-24 18:09     ` Will Deacon
2014-09-24 18:09       ` Will Deacon
2014-09-25  5:03     ` Ingo Molnar
2014-09-25  5:03       ` Ingo Molnar

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=20140509183241.GA4491@samfundet.no \
    --to=egtvedt@samfundet.no \
    --cc=akpm@linux-foundation.org \
    --cc=hskinnemoen@gmail.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=torvalds@linux-foundation.org \
    --cc=will.deacon@arm.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).