From: Kenneth Lee <hidden> Date: 2016-08-30 06:17:41
(add comment for the previous mail, sorry for the duplication)
There is no store_ex pairing with this load_ex. It is not necessary and
gave wrong hint to the cache system.
Signed-off-by: Kenneth Lee <redacted>
---
arch/arm64/include/asm/spinlock.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
On Tue, Aug 30, 2016 at 02:35:31PM +0800, Kenneth Lee wrote:
quoted hunk
(add comment for the previous mail, sorry for the duplication)
There is no store_ex pairing with this load_ex. It is not necessary and
gave wrong hint to the cache system.
Signed-off-by: Kenneth Lee <redacted>
---
arch/arm64/include/asm/spinlock.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
This is needed because the arch_spin_unlock() code only uses an STLR
without an explicit SEV (like we have on AArch32). An event is
automatically generated when the exclusive monitor is cleared by STLR.
But without setting it with a load exclusive in arch_spin_lock() (even
though it does not acquire the lock), there won't be anything to clear,
hence no event to be generated. In this case, the WFE would wait
indefinitely.
--
Catalin
From: Vladimir Murzin <hidden> Date: 2016-08-31 13:31:04
On 30/08/16 10:07, Catalin Marinas wrote:
On Tue, Aug 30, 2016 at 02:35:31PM +0800, Kenneth Lee wrote:
quoted
(add comment for the previous mail, sorry for the duplication)
There is no store_ex pairing with this load_ex. It is not necessary and
gave wrong hint to the cache system.
Signed-off-by: Kenneth Lee <redacted>
---
arch/arm64/include/asm/spinlock.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
This is needed because the arch_spin_unlock() code only uses an STLR
without an explicit SEV (like we have on AArch32). An event is
automatically generated when the exclusive monitor is cleared by STLR.
But without setting it with a load exclusive in arch_spin_lock() (even
though it does not acquire the lock), there won't be anything to clear,
hence no event to be generated. In this case, the WFE would wait
indefinitely.
Maybe worth to add this as a comment, no?
Cheers
Vladimir
Thanks for the clarification.
Add a comment there will be nice:)
-Kenneth Lee (Hisilicon)
-----????-----
???: Catalin Marinas [mailto:catalin.marinas at arm.com]
????: 2016?8?30? 17:07
???: Liguozhu (Kenneth)
??: Will Deacon; linux-kernel at vger.kernel.org; linux-arm-kernel at lists.infradead.org
??: Re: [PATCH] [bugfix] replace unnessary ldax with common ldr
On Tue, Aug 30, 2016 at 02:35:31PM +0800, Kenneth Lee wrote:
quoted hunk
(add comment for the previous mail, sorry for the duplication)
There is no store_ex pairing with this load_ex. It is not necessary and
gave wrong hint to the cache system.
Signed-off-by: Kenneth Lee <redacted>
---
arch/arm64/include/asm/spinlock.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
This is needed because the arch_spin_unlock() code only uses an STLR
without an explicit SEV (like we have on AArch32). An event is
automatically generated when the exclusive monitor is cleared by STLR.
But without setting it with a load exclusive in arch_spin_lock() (even
though it does not acquire the lock), there won't be anything to clear,
hence no event to be generated. In this case, the WFE would wait
indefinitely.
--
Catalin
On Wed, Aug 31, 2016 at 02:30:40PM +0100, Vladimir Murzin wrote:
On 30/08/16 10:07, Catalin Marinas wrote:
quoted
On Tue, Aug 30, 2016 at 02:35:31PM +0800, Kenneth Lee wrote:
quoted
(add comment for the previous mail, sorry for the duplication)
There is no store_ex pairing with this load_ex. It is not necessary and
gave wrong hint to the cache system.
Signed-off-by: Kenneth Lee <redacted>
---
arch/arm64/include/asm/spinlock.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
This is needed because the arch_spin_unlock() code only uses an STLR
without an explicit SEV (like we have on AArch32). An event is
automatically generated when the exclusive monitor is cleared by STLR.
But without setting it with a load exclusive in arch_spin_lock() (even
though it does not acquire the lock), there won't be anything to clear,
hence no event to be generated. In this case, the WFE would wait
indefinitely.
Maybe worth to add this as a comment, no?
Yes, we just need to find someone to send a patch ;).
--
Catalin