3rd-party/linux-kernel-module-cheat
1
0
Fork 0
mirror of https://github.com/cirosantilli/linux-kernel-module-cheat.git synced 2026-01-23 02:05:57 +01:00
Code Issues Releases Wiki Activity

armv8 spinlock with wfe

Browse Source
This commit is contained in:
Ciro Santilli 六四事件 法轮功
2019-12-24 00:00:00 +00:00
parent 657c59249e
commit 2cfe56decf
1 changed files with 16 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
README.adoc
View File

@@ -18749,9 +18749,25 @@ so we conclude that:
* the second WFE made the CPU stop running instructions at time 112285501668498000 and PC 0x40007c * 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 <<arm-timer>> * the next thing that happened a long time later (112285501909320500, while a following instruction would happen at 112285501668498000 + 1000) was an interrupt, presumably the <<arm-timer>>
* after a few interrupt handler instructions, the first <<arm-svc-instruction,ERET>> instruction exits the handler and comes back directly to the instruction after the WFE at PC 0x400080 == 0x40007c + 4 * after a few interrupt handler instructions, the first <<arm-svc-instruction,ERET>> 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. 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 <<arm-ldxr-and-stxr-instructions,STXR>> 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 ARM WFE
gem5 390a74f59934b85d91489f8a563450d8321b602d does not sleep on the first WFE on either syscall emulation or full system, because the code does: gem5 390a74f59934b85d91489f8a563450d8321b602d does not sleep on the first WFE on either syscall emulation or full system, because the code does: