#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