1. 29 Feb, 2008 5 commits
    • 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: serialize SLB invalidation against SLB loading · c92a1acb
      Arnd Bergmann authored
      There is a potential race between flushes of the entire SLB in the MFC
      and the point where new entries are being established. The problem is
      that we might put a ESID entry into the MFC SLB when the VSID entry has
      just been cleared by the global flush.
      
      This can be circumvented by holding the register_lock throughout both
      the flushing and the creation of SLB entries.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarJeremy Kerr <jk@ozlabs.org>
      c92a1acb
    • Arnd Bergmann's avatar
      [POWERPC] spufs: invalidate SLB translation before adding a new entry · cc4b7c18
      Arnd Bergmann authored
      When we replace an SLB entry in the MFC after using up all the available
      entries, there is a short window in which an incorrect entry is marked
      as valid.
      
      The problem is that the 'valid' bit is stored in the ESID, which is
      always written after the VSID. Overwriting the VSID first will make the
      original ESID entry point to the new VSID, which means that any
      concurrent DMA accessing the old ESID ends up being redirected to the
      new virtual address.  A few cycles later, we write the new ESID and
      everything is fine again.
      
      That race can be closed by writing a zero entry to the ESID first, which
      makes sure that the VSID is not accessed until we write the new ESID.
      
      Note that we don't actually need to invalidate the SLB entry using the
      invalidation register, which would also flush any ERAT entries for that
      segment, because the segment translation does not become invalid but is
      only removed from the SLB cache.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarJeremy Kerr <jk@ozlabs.org>
      cc4b7c18
    • 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
  2. 27 Feb, 2008 2 commits
    • 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
  3. 20 Feb, 2008 1 commit
  4. 18 Feb, 2008 1 commit
    • Jeremy Kerr's avatar
      [POWERPC] spufs: fix scheduler starvation by idle contexts · 4ef11014
      Jeremy Kerr authored
      2.6.25 has a regression where we can starve the scheduler by creating
      (N_SPES+1) contexts, then running them one at a time.
      
      The final context will never be run, as the other contexts are loaded on
      the SPEs, none of which are repoted as free (ie, spu->alloc_state !=
      SPU_FREE), so spu_get_idle() doesn't give us a spu to run on. Because
      all of the contexts are stopped, none are descheduled by the scheduler
      tick, as spusched_tick returns if spu_stopped(ctx).
      
      This change replaces the spu_stopped() check with checking for SCHED_IDLE
      in ctx->policy. We set a context's policy to SCHED_IDLE when we're not
      in spu_run(). We also favour SCHED_IDLE contexts when looking for contexts
      to unbind, but leave their timeslice intact for later resumption.
      
      This patch fixes the following test in the spufs-testsuite:
        tests/20-scheduler/02-yield-starvation
      Signed-off-by: default avatarJeremy Kerr <jk@ozlabs.org>
      4ef11014
  5. 15 Feb, 2008 31 commits