diff --git a/index.html b/index.html index 88d37e2..9f05d46 100644 --- a/index.html +++ b/index.html @@ -1271,6 +1271,7 @@ body.book #toc,body.book #preamble,body.book h1.sect0,body.book .sect1>h2{page-b
  • 21.2.1. C++ multithreading
  • 21.2.2. C++ standards @@ -22826,6 +22827,15 @@ time ./mutex.out 4 100000000 +
    +
    21.2.1.2. C++ parallel algorithms
    +
    +

    https://stackoverflow.com/questions/51031060/are-c17-parallel-algorithms-implemented-already/55989883#55989883

    +
    +
    +

    userland/cpp/parallel_sort.cpp

    +
    +

    21.2.2. C++ standards

    @@ -30258,7 +30268,7 @@ IN: main
    • -

      WFE puts the core in a low power mode

      +

      WFE is intended to put the core in a low power mode

    • SEV wakes up cores from a low power mode

      @@ -30269,6 +30279,48 @@ IN: main

      and power consumption is key in ARM applications.

    +

    SEV is not the only thing that can wake up a WFE, it is only an explicit software way to do it. Notably, global monitor operations on memory accesses of regions marked by LDREX and STREX instructions can also wake up a WFE sleeping core. This is done to allow spinlocks opens to automatically wake up WFE sleeping cores at free time without the need for a explicit SEV.

    +
    +
    +

    WFE and SEV are usable from userland, and are part of a efficient spinlock implementation.

    +
    +
    +

    Quotes for the above ARMv8 architecture reference manual db G1.18.1 "Wait For Event and Send Event":

    +
    +
    +
    +
    +

    The following events are WFE wake-up events:

    +
    +
    +

    \[…​]

    +
    +
    +
      +
    • +

      An event caused by the clearing of the global monitor associated with the PE

      +
      • +
    +
    +
    +
    +
    +

    and ARMv8 architecture reference manual db E2.9.6 "Use of WFE and SEV instructions by spin-locks":

    +
    +
    +
    +
    +

    ARMv8 provides Wait For Event, Send Event, and Send Event Local instructions, WFE, SEV, SEVL, that can assist with reducing power consumption and bus contention caused by PEs repeatedly attempting to obtain a spin-lock. These instructions can be used at the application level, but a complete understanding of what they do depends on a system level understanding of exceptions. They are described in Wait For Event and Send Event on page G1-5308. However, in ARMv8, when the global monitor for a PE changes from Exclusive Access state to Open Access state, an event is generated.

    +
    +
    +

    Note This is equivalent to issuing an SEVL instruction on the PE for which the monitor state has changed. It removes the need for spinlock code to include an SEV instruction after clearing a spinlock.

    +
    +
    +
    +
    +

    The recommended ARMv8 spinlock implementation is shown at http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dht0008a/ch01s03s02.html where WAIT_FOR_UPDATE is as explained in that section a macro that expands to WFE.

    +
    +

    In QEMU 3.0.0, SEV is a NOPs, and WFE might be, but I’m not sure, see: https://github.com/qemu/qemu/blob/v3.0.0/target/arm/translate-a64.c#L1423

    @@ -30299,7 +30351,7 @@ IN: main
    -

    For gem5 however, if we comment out the SVE instruction, then it actually exits with simulate() limit reached, so the CPU truly never wakes up, which is a more realistic behaviour.

    +

    For gem5 however, if we comment out the SVE instruction, then it actually exits with simulate() limit reached, so the CPU truly never wakes up, which is a more realistic behaviour, since gem5 is more focused on simulating a realistic microarchitecture and power consumption.

    The following Raspberry Pi bibliography helped us get this sample up and running: