1. 29 2月, 2008 1 次提交
    • J
      [POWERPC] spufs: fix order of sputrace thread IDs · 71791bee
      Jeremy Kerr 提交于
      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: NJeremy Kerr <jk@ozlabs.org>
      71791bee
  2. 28 2月, 2008 1 次提交
    • J
      [POWERPC] spufs: fix invalid scheduling of forgotten contexts · 0111a701
      Jeremy Kerr 提交于
      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: NJeremy Kerr <jk@ozlabs.org>
      0111a701
  3. 27 2月, 2008 1 次提交
    • J
      [POWERPC] spufs: fix context destruction during psmap fault · d5883137
      Jeremy Kerr 提交于
      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: NJeremy Kerr <jk@ozlabs.org>
      d5883137
  4. 20 2月, 2008 1 次提交
  5. 19 2月, 2008 1 次提交
    • J
      [POWERPC] spufs: fix scheduler starvation by idle contexts · 4ef11014
      Jeremy Kerr 提交于
      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: NJeremy Kerr <jk@ozlabs.org>
      4ef11014
  6. 16 2月, 2008 3 次提交
  7. 15 2月, 2008 32 次提交