[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:                    |  
---------------------------------+------------------------------------------

Comment(by njd):

 I'd like to add a word of caution to the inclusion of any form of
 priority/weighted scheduling into GHC at this time.

 Scheduling (unless it discards work) does not, a priori, change the
 total amount of work that has to be done, just its order. Such
 scheduling strategies don't create computational power, they just
 distribute the "disappointment" of not being first...

 This would imply that all of the timing changes reported in this
 thread are the result of interactions with other resources - different
 patterns of memory access, garbage collection etc.

 The community already recognises these sort of performance couplings
 and there several mechanisms (at a higher level) that can be used to
 manage the inevitable performance trades.

 I strongly believe that adding differential scheduling at this time
 will be, overall, counter productive to GHC's RTS development. It will
 create a new class of performance artefacts that will require
 resources to investigate. Time will be spent pushing trades around,
 chasing the proverbial bubble under the wall paper around and around.

 Please don't get me wrong, I am highly appreciative of Edward's
 efforts. The more overhead we can reduce in the scheduling, the
 better.

 If we want to start looking at more complex differential treatment of
 the allocation of supply (cpu cycles) to demand (task steps) then we
 need to consider the issues of how that trade interacts with the
 others. And how the overall trading space is going to manifest itself
 in terms of end-user goals. We also need to come up with a sensible
 approach of how to discard computational demand (load shedding) when
 the "system" becomes "excessively" infeasible to schedule to met those
 goals. Fortunately there are approaches to this (stuff I've been
 involved with in data networks for many years) - and Haskell's
 operational has all the right hooks in to do this. Interested PhD
 students, do get in touch....

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