From 2cfe56decf51bd28ee7e0d7db44b9aa22a23b028 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ciro=20Santilli=20=E5=85=AD=E5=9B=9B=E4=BA=8B=E4=BB=B6=20?= =?UTF-8?q?=E6=B3=95=E8=BD=AE=E5=8A=9F?= Date: Tue, 24 Dec 2019 00:00:00 +0000 Subject: [PATCH] armv8 spinlock with wfe --- README.adoc | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/README.adoc b/README.adoc index a7e71db..26ffeeb 100644 --- a/README.adoc +++ b/README.adoc @@ -18749,9 +18749,25 @@ so we conclude that: * the second WFE made the CPU stop running instructions at time 112285501668498000 and PC 0x40007c * the next thing that happened a long time later (112285501909320500, while a following instruction would happen at 112285501668498000 + 1000) was an interrupt, presumably the <> * after a few interrupt handler instructions, the first <> instruction exits the handler and comes back directly to the instruction after the WFE at PC 0x400080 == 0x40007c + 4 +* the execution of the interrupt handler woke up the core that was in WFE, and it now continues normal execution past the WFE Therefore, a WFE in userland is treated much like a busy loop by the Linux kernel: the kernel does not seem to try and explicitly make up room for other processes as would happen on a futex. +====== ARMv8 spinlock pattern + +http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka16277.html + +.... + sev + 1: wfe + 2: ldaxr w1, [w0] + cbnz w1, %1b + stxr w1, w2, [w0] + cbnz w1, %2b +.... + +It is the <> from the unlock on another core that automatically wakes up the spinlock afterwards: https://stackoverflow.com/questions/32276313/how-is-a-spin-lock-woken-up-in-linux-arm64 + ====== gem5 ARM WFE gem5 390a74f59934b85d91489f8a563450d8321b602d does not sleep on the first WFE on either syscall emulation or full system, because the code does: