1. 02 9月, 2009 3 次提交
  2. 28 8月, 2009 13 次提交
  3. 27 8月, 2009 3 次提交
    • G
      powerpc/pseries: Reduce the polling interval in __cpu_up() · 67764263
      Gautham R Shenoy 提交于
      Time time taken for a single cpu online operation on a pseries machine
      is as follows:
      Dedicated LPAR (POWER6): ~220ms.
      Shared LPAR (POWER5)   : ~240ms.
      
      Of this time, approximately 200ms is taken up by __cpu_up(). This is because
      we poll every 200ms to check if the new cpu has notified it's presence
      through the cpu_callin_map. We repeat this operation until the new cpu sets
      the value in cpu_callin_map or 5 seconds elapse, whichever comes earlier.
      
      However, using completion_structs instead of polling loops,
      the time taken by the new processor to indicate it's presence has
      found to be less than 1ms on pseries. This method however may not
      work on all powerpc platforms due to the time-base synchronization code.
      
      Keeping this in mind, we could reduce msleep polling interval from
      200ms to 1ms while retaining the 5 second timeout.
      
      With this, the time taken for a cpu online operation changes as follows:
      Dedicated LPAR (POWER6): 20-25ms.
      Shared LPAR (POWER5)   : 60-80ms.
      
      In both these cases, it was found that the code polls through the loop
      only once indicating that 1ms is a reasonable value, atleast on pseries.
      
      The code needs testing on other powerpc platforms.
      Signed-off-by: NGautham R Shenoy <ego@in.ibm.com>
      Acked-by: NJoel Schopp <jschopp@austin.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      67764263
    • J
      powerpc: Fix __flush_icache_range on 44x · 14d75752
      Josh Boyer 提交于
      The ptrace POKETEXT interface allows a process to modify the text pages of
      a child process being ptraced, usually to insert breakpoints via trap
      instructions.  The kernel eventually calls copy_to_user_page, which in turn
      calls __flush_icache_range to invalidate the icache lines for the child
      process.
      
      However, this function does not work on 44x due to the icache being virtually
      indexed.  This was noticed by a breakpoint being triggered after it had been
      cleared by ltrace on a 440EPx board.  The convenient solution is to do a
      flash invalidate of the icache in the __flush_icache_range function.
      Signed-off-by: NJosh Boyer <jwboyer@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      14d75752
    • B
      powerpc/mm: Cleanup handling of execute permission · ea3cc330
      Benjamin Herrenschmidt 提交于
      This is an attempt at cleaning up a bit the way we handle execute
      permission on powerpc. _PAGE_HWEXEC is gone, _PAGE_EXEC is now only
      defined by CPUs that can do something with it, and the myriad of
      #ifdef's in the I$/D$ coherency code is reduced to 2 cases that
      hopefully should cover everything.
      
      The logic on BookE is a little bit different than what it was though
      not by much. Since now, _PAGE_EXEC will be set by the generic code
      for executable pages, we need to filter out if they are unclean and
      recover it. However, I don't expect the code to be more bloated than
      it already was in that area due to that change.
      
      I could boast that this brings proper enforcing of per-page execute
      permissions to all BookE and 40x but in fact, we've had that now for
      some time as a side effect of my previous rework in that area (and
      I didn't even know it :-) We would only enable execute permission if
      the page was cache clean and we would only cache clean it if we took
      and exec fault. Since we now enforce that the later only work if
      VM_EXEC is part of the VMA flags, we de-fact already enforce per-page
      execute permissions... Unless I missed something
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      ea3cc330
  4. 20 8月, 2009 18 次提交
  5. 18 8月, 2009 2 次提交
    • P
      perf_counter: powerpc: Add callchain support · 20002ded
      Paul Mackerras 提交于
      This adds support for tracing callchains for powerpc, both 32-bit
      and 64-bit, and both in the kernel and userspace, from PMU interrupt
      context.
      
      The first three entries stored for each callchain are the NIP (next
      instruction pointer), LR (link register), and the contents of the LR
      save area in the second stack frame (the first is ignored because the
      ABI convention on powerpc is that functions save their return address
      in their caller's stack frame).  Because leaf functions don't have to
      save their return address (LR value) and don't have to establish a
      stack frame, it's possible for either or both of LR and the second
      stack frame's LR save area to have valid return addresses in them.
      This is basically impossible to disambiguate without either reading
      the code or looking at auxiliary information such as CFI tables.
      Since we don't want to do either of those things at interrupt time,
      we store both LR and the second stack frame's LR save area.
      
      Once we get past the second stack frame, there is no ambiguity; all
      return addresses we get are reliable.
      
      For kernel traces, we check whether they are valid kernel instruction
      addresses and store zero instead if they are not (rather than
      omitting them, which would make it impossible for userspace to know
      which was which).  We also store zero instead of the second stack
      frame's LR save area value if it is the same as LR.
      
      For kernel traces, we check for interrupt frames, and for user traces,
      we check for signal frames.  In each case, since we're starting a new
      trace, we store a PERF_CONTEXT_KERNEL/USER marker so that userspace
      knows that the next three entries are NIP, LR and the second stack frame
      for the interrupted context.
      
      We read user memory with __get_user_inatomic.  On 64-bit, if this
      PMU interrupt occurred while interrupts are soft-disabled, and
      there is no MMU hash table entry for the page, we will get an
      -EFAULT return from __get_user_inatomic even if there is a valid
      Linux PTE for the page, since hash_page isn't reentrant.  Thus we
      have code here to read the Linux PTE and access the page via the
      kernel linear mapping.  Since 64-bit doesn't use (or need) highmem
      there is no need to do kmap_atomic.  On 32-bit, we don't do soft
      interrupt disabling, so this complication doesn't occur and there
      is no need to fall back to reading the Linux PTE, since hash_page
      (or the TLB miss handler) will get called automatically if necessary.
      
      Note that we cannot get PMU interrupts in the interval during
      context switch between switch_mm (which switches the user address
      space) and switch_to (which actually changes current to the new
      process).  On 64-bit this is because interrupts are hard-disabled
      in switch_mm and stay hard-disabled until they are soft-enabled
      later, after switch_to has returned.  So there is no possibility
      of trying to do a user stack trace when the user address space is
      not current's address space.
      Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      20002ded
    • P
      powerpc: Allow perf_counters to access user memory at interrupt time · 9c1e1052
      Paul Mackerras 提交于
      This provides a mechanism to allow the perf_counters code to access
      user memory in a PMU interrupt routine.  Such an access can cause
      various kinds of interrupt: SLB miss, MMU hash table miss, segment
      table miss, or TLB miss, depending on the processor.  This commit
      only deals with 64-bit classic/server processors, which use an MMU
      hash table.  32-bit processors are already able to access user memory
      at interrupt time.  Since we don't soft-disable on 32-bit, we avoid
      the possibility of reentering hash_page or the TLB miss handlers,
      since they run with interrupts disabled.
      
      On 64-bit processors, an SLB miss interrupt on a user address will
      update the slb_cache and slb_cache_ptr fields in the paca.  This is
      OK except in the case where a PMU interrupt occurs in switch_slb,
      which also accesses those fields.  To prevent this, we hard-disable
      interrupts in switch_slb.  Interrupts are already soft-disabled at
      this point, and will get hard-enabled when they get soft-enabled
      later.
      
      This also reworks slb_flush_and_rebolt: to avoid hard-disabling twice,
      and to make sure that it clears the slb_cache_ptr when called from
      other callers than switch_slb, the existing routine is renamed to
      __slb_flush_and_rebolt, which is called by switch_slb and the new
      version of slb_flush_and_rebolt.
      
      Similarly, switch_stab (used on POWER3 and RS64 processors) gets a
      hard_irq_disable() to protect the per-cpu variables used there and
      in ste_allocate.
      
      If a MMU hashtable miss interrupt occurs, normally we would call
      hash_page to look up the Linux PTE for the address and create a HPTE.
      However, hash_page is fairly complex and takes some locks, so to
      avoid the possibility of deadlock, we check the preemption count
      to see if we are in a (pseudo-)NMI handler, and if so, we don't call
      hash_page but instead treat it like a bad access that will get
      reported up through the exception table mechanism.  An interrupt
      whose handler runs even though the interrupt occurred when
      soft-disabled (such as the PMU interrupt) is considered a pseudo-NMI
      handler, which should use nmi_enter()/nmi_exit() rather than
      irq_enter()/irq_exit().
      Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      9c1e1052
  6. 10 8月, 2009 1 次提交