[GHC] #7606: Stride scheduling for Haskell threads with priorities

[GHC]

#7606: Stride scheduling for Haskell threads with priorities
---------------------------------+------------------------------------------
    Reporter:  ezyang            |       Owner:  ezyang          
        Type:  feature request   |      Status:  new             
    Priority:  normal            |   Milestone:  7.8.1           
   Component:  Runtime System    |     Version:  7.7             
    Keywords:                    |          Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  |     Failure:  None/Unknown    
  Difficulty:  Unknown           |    Testcase:                  
   Blockedby:                    |    Blocking:                  
     Related:                    |  
---------------------------------+------------------------------------------
Changes (by simonmar):

  * difficulty:  => Unknown
  * milestone:  => 7.8.1


Comment:

 Awesome!

 Ok, to get started on the reviewing process, I'll jot down some concerns.

  * First, nofib has zero concurrency benchmarks in it, so the results
 aren't very meaningful.  Still, you seem to have some outliers in there -
 any idea why?  nofib/smp has some concurrency benchmarks that I normally
 use when making changes to the scheduler.

  * Run all the tests in `testsuite/concurrent`.  They aren't run by
 default in a validate.

  * The patch adds no less than 4 fields to the TSO struct, which is quite
 a lot.  We should benchmark carefully to make sure this isn't a problem.

  * Why stride scheduling rather than something else, e.g. Linux's CFS?
 Wouldn't CFS address the issue of giving more time to blocked threads?
 What about inaccuracies due to the time it takes for a thread to respond
 to the timer signal?

  * Currently, if there's a very long run queue, a minor GC won't have to
 traverse a lot of it because it will be in the old generation, but here
 the GC has to look at every element of the priority queue.  We should make
 a benchmark with a long run queue and see if that's an issue.

  * `promoteInRunQueue`: it would be a shame to lose this, but as long as
 we're sure that #3838 hasn't regressed it should be ok.

  * could we have some more docs on the scheduler functions,
 `capPassUpdate` etc. please?

  * Looks like we should do `annulTSO` in a better way.  These fields
 should be empty normally, set when a thread is blocked, and unset again
 when the thread is unblocked.

  * I don't see why `sched_mutex` is needed in `setTickets` and co.  Could
 you explain?

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7606#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler