Skip to content
  1. Jun 16, 2008
  2. May 15, 2008
  3. May 08, 2008
  4. May 05, 2008
  5. May 01, 2008
  6. Apr 30, 2008
  7. Apr 29, 2008
  8. Apr 19, 2008
  9. Apr 01, 2008
  10. Mar 28, 2008
  11. Mar 11, 2008
    • Jeremy Kerr's avatar
      [POWERPC] spufs: fix rescheduling of non-runnable contexts · c368392a
      Jeremy Kerr authored
      
      
      At present, we can hit the BUG_ON in __spu_update_sched_info by reading
      the regs file of a context between two calls to spu_run. The
      spu_release_saved called by spufs_regs_read() is resulting in the (now
      non-runnable) context being placed back on the run queue, so the next
      call to spu_run ends up in the bug condition.
      
      This change uses the SPU_SCHED_SPU_RUN flag to only reschedule a context
      if it's still in spu_run().
      
      Signed-off-by: default avatarJeremy Kerr <jk@ozlabs.org>
      c368392a
    • Jeremy Kerr's avatar
      [POWERPC] spufs: don't (ab)use SCHED_IDLE · ce7c191b
      Jeremy Kerr authored
      
      
      commit 4ef11014 introduced a usage of SCHED_IDLE to detect when
      a context is within spu_run.
      
      Instead of SCHED_IDLE (which has other meaning), add a flag to
      sched_flags to tell if a context should be running.
      
      Signed-off-by: default avatarJeremy Kerr <jk@ozlabs.org>
      ce7c191b
  12. Feb 29, 2008
    • Andre Detsch's avatar
      [POWERPC] spufs: fix use time accounting on SPE-overcommit · 2a58aa33
      Andre Detsch authored
      
      
      The spu_runcntl_RW register is restored within spu_restore function.
      So, at the end of spu_bind_context, the SPU context is not just loaded,
      but running.
      
      This change corrects the state switch to account the time as USER.
      
      Signed-off-by: default avatarAndre Detsch <adetsch@br.ibm.com>
      Signed-off-by: default avatarJeremy Kerr <jk@ozlabs.org>
      2a58aa33
    • Arnd Bergmann's avatar
      [POWERPC] spufs: synchronize IRQ when disabling · fae9ca79
      Arnd Bergmann authored
      
      
      There is a small race between the context save procedure
      and the SPU interrupt handling, where we expect all interrupt
      processing to have finished after disabling them, while
      an interrupt is still being processed on another CPU.
      
      The obvious fix is to call synchronize_irq() after disabling
      the interrupts at the start of the context save procedure
      to make sure we never access the SPU any more during an
      ongoing save or even after that.
      
      Thanks to Benjamin Herrenschmidt for pointing this out.
      
      Acked-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarJeremy Kerr <jk@ozlabs.org>
      fae9ca79
    • Jeremy Kerr's avatar
      [POWERPC] spufs: fix order of sputrace thread IDs · 71791bee
      Jeremy Kerr authored
      
      
      Currently, we get the following output from sputrace:
      
      [5.097935954] 1606: spufs_ps_nopfn__enter (thread = 1605, spu = -1)
      [5.097958164] 1606: spufs_ps_nopfn__insert (thread = 1605, spu = 15)
      [5.097973529] 1607: spufs_ps_nopfn__enter (thread = 1605, spu = -1)
      [5.097989174] 1607: spufs_ps_nopfn__insert (thread = 1605, spu = 14)
      
      Which leads me to believe that 160[67] is the current thread ID, and
      1605 is the context backing the psmap.
      
      However, the 'current' and 'owner' tids are reversed - the 'current'
      tid is on the right. This change puts the current thread ID in the
      left-hand column instead, and renames the right to 'ctxthread'.
      
      Signed-off-by: default avatarJeremy Kerr <jk@ozlabs.org>
      71791bee
  13. Feb 27, 2008
    • Jeremy Kerr's avatar
      [POWERPC] spufs: fix invalid scheduling of forgotten contexts · 0111a701
      Jeremy Kerr authored
      
      
      At present, we have a situation where a context with no owner is
      re-scheduled by spu_forget:
      
      	Thread 1: reading regs file	Thread 2: context owner
      
      					spu_forget()
      						- ctx->owner = NULL
      						- set SPU_SCHED_WAS_ACTIVE
      
      	spu_acquire_saved()
      	- context is in saved state
      
      	spu_release_saved()
      	- SPU_SCHED_WAS_ACTIVE is set,
      	  so spu_activate() the context,
      	  which now has no owner
      
      In spu_forget(), we shouldn't be requesting a re-schedule by setting
      SPU_SCHED_WAS_ACTIVE. This change removes the set_bit in spu_forget(),
      so that spu_release_saved() doesn't reinsert this destroyed context on
      to the run queue.
      
      Signed-off-by: default avatarJeremy Kerr <jk@ozlabs.org>
      0111a701
    • Jeremy Kerr's avatar
      [POWERPC] spufs: fix context destruction during psmap fault · d5883137
      Jeremy Kerr authored
      
      
      We have a small window where a spu context may be destroyed while
      we're servicing a page fault (from another thread) to the context's
      problem state mapping.
      
      After we up_read() the mmap_sem, it's possible that the context is
      destroyed by its owning thread, and so the later references to ctx
      are invalid. This can maifest as a deadlock on the (now free()-ed)
      context state mutex.
      
      This change adds a reference to the context before we release the
      mmap_sem, so that the context cannot be destroyed.
      
      Signed-off-by: default avatarJeremy Kerr <jk@ozlabs.org>
      d5883137
  14. Feb 20, 2008
Loading