1. 04 Jul, 2017 1 commit
  2. 03 Jul, 2017 17 commits
  3. 02 Jul, 2017 19 commits
  4. 28 Jun, 2017 3 commits
    • Nicholas Piggin's avatar
      spin loop primitives for busy waiting · fd851a3c
      Nicholas Piggin authored
      Current busy-wait loops are implemented by repeatedly calling cpu_relax()
      to give an arch option for a low-latency option to improve power and/or
      SMT resource contention.
      
      This poses some difficulties for powerpc, which has SMT priority setting
      instructions (priorities determine how ifetch cycles are apportioned).
      powerpc's cpu_relax() is implemented by setting a low priority then
      setting normal priority. This has several problems:
      
       - Changing thread priority can have some execution cost and potential
         impact to other threads in the core. It's inefficient to execute them
         every time around a busy-wait loop.
      
       - Depending on implementation details, a `low ; medium` sequence may
         not have much if any affect. Some software with similar pattern
         actually inserts a lot of nops between, in order to cause a few fetch
         cycles with the low priority.
      
       - The busy-wait loop runs with regular priority. This might only be a few
         fetch cycles, but if there are several threads running such loops, they
         could cause a noticable impact on a non-idle thread.
      
      Implement spin_begin, spin_end primitives that can be used around busy
      wait loops, which default to no-ops. And spin_cpu_relax which defaults to
      cpu_relax.
      
      This will allow architectures to hook the entry and exit of busy-wait
      loops, and will allow powerpc to set low SMT priority at entry, and
      normal priority at exit.
      Suggested-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarNicholas Piggin <npiggin@gmail.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      fd851a3c
    • Akshay Adiga's avatar
      powerpc/powernv/idle: Clear r12 on wakeup from stop lite · 4d0d7c02
      Akshay Adiga authored
      pnv_wakeup_noloss() expects r12 to contain SRR1 value to determine if the wakeup
      reason is an HMI in CHECK_HMI_INTERRUPT.
      
      When we wakeup with ESL=0, SRR1 will not contain the wakeup reason, so there is
      no point setting r12 to SRR1.
      
      However, we don't set r12 at all so r12 contains garbage (likely a kernel
      pointer), and is still used to check HMI assuming that it contained SRR1. This
      causes the OPAL msglog to be filled with the following print:
      
        HMI: Received HMI interrupt: HMER = 0x0040000000000000
      
      This patch clears r12 after waking up from stop with ESL=EC=0, so that we don't
      accidentally enter the HMI handler in pnv_wakeup_noloss() if the value of
      r12[42:45] corresponds to HMI as wakeup reason.
      
      Prior to commit 9d292501 ("powerpc/64s/idle: Avoid SRR usage in idle
      sleep/wake paths") this bug existed, in that we would incorrectly look at SRR1
      to check for a HMI when SRR1 didn't contain a wakeup reason. However the SRR1
      value would just happen to never have bits 42:45 set.
      
      Fixes: 9d292501 ("powerpc/64s/idle: Avoid SRR usage in idle sleep/wake paths")
      Signed-off-by: default avatarAkshay Adiga <akshay.adiga@linux.vnet.ibm.com>
      Reviewed-by: default avatarNicholas Piggin <npiggin@gmail.com>
      [mpe: Change log and comment massaging]
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      4d0d7c02
    • Anshuman Khandual's avatar
      powerpc/mm: Add comments on vmemmap physical mapping · 39e46751
      Anshuman Khandual authored
      Adds some explaination on how the vmemmap based struct page layout's
      physical mapping is allocated and tracked through linked list. It
      also keeps note of a possible race condition.
      Signed-off-by: default avatarAnshuman Khandual <khandual@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      39e46751