Re: [Xen-devel] [PATCH v2 05/17] xen: arm32: resync atomics with (almost) v3.14-rc7

[Julien Grall <julien.grall@xxxxxxxxxx>]

On 03/26/2014 01:38 PM, Ian Campbell wrote:
> Almost because I omitting aed3a4e "ARM: 7868/1: arm/arm64: remove
> atomic_clear_mask() ..." which I will apply to both arm32 and arm64
> simultaneously in a later patch.
> 
> This pulls in the following Linux patches:
> 
> commit f38d999c4d16fc0fce4270374f15fbb2d8713c09
> Author: Will Deacon <will.deacon@xxxxxxx>
> Date:   Thu Jul 4 11:43:18 2013 +0100
> 
>     ARM: atomics: prefetch the destination word for write prior to strex
> 
>     The cost of changing a cacheline from shared to exclusive state can be
>     significant, especially when this is triggered by an exclusive store,
>     since it may result in having to retry the transaction.
> 
>     This patch prefixes our atomic access implementations with pldw
>     instructions (on CPUs which support them) to try and grab the line in
>     exclusive state from the start. Only the barrier-less functions are
>     updated, since memory barriers can limit the usefulness of prefetching
>     data.
> 
>     Acked-by: Nicolas Pitre <nico@xxxxxxxxxx>
>     Signed-off-by: Will Deacon <will.deacon@xxxxxxx>
> 
> commit 4dcc1cf7316a26e112f5c9fcca531ff98ef44700
> Author: Chen Gang <gang.chen@xxxxxxxxxxx>
> Date:   Sat Oct 26 15:07:25 2013 +0100
> 
>     ARM: 7867/1: include: asm: use 'int' instead of 'unsigned long' for 
> 'oldval
> 
>     For atomic_cmpxchg(), the type of 'oldval' need be 'int' to match the
>     type of "*ptr" (used by 'ldrex' instruction) and 'old' (used by 'teq'
>     instruction).
> 
>     Reviewed-by: Will Deacon <will.deacon@xxxxxxx>
>     Signed-off-by: Chen Gang <gang.chen@xxxxxxxxxxx>
>     Signed-off-by: Will Deacon <will.deacon@xxxxxxx>
>     Signed-off-by: Russell King <rmk+kernel@xxxxxxxxxxxxxxxx>
> 
> Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
Acked-by: Julien Grall <julien.grall@xxxxxxxxxx>


-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel