Another try to get thread migration right
authorSimon Marlow <marlowsd@gmail.com>
Thu, 4 Aug 2016 14:59:43 +0000 (15:59 +0100)
committerSimon Marlow <marlowsd@gmail.com>
Fri, 5 Aug 2016 09:13:28 +0000 (10:13 +0100)
commit89fa4e968f47cfb42d0dc33fc3bfffdce31d850e
tree1856b779db9349c24390886ebdb1694cf207a568
parentce13a9a9f57d61170837532948fed8bc1924a7ab
Another try to get thread migration right

Summary:
This is surprisingly tricky.  There were linked list bugs in the
previous version (D2430) that showed up as a test failure in
setnumcapabilities001 (that's a great stress test!).

This new version uses a different strategy that doesn't suffer from
the problem that @ezyang pointed out in D2430.  We now pre-calculate
how many threads to keep for this capability, and then migrate any
surplus threads off the front of the queue, taking care to account for
threads that can't be migrated.

Test Plan:
1. setnumcapabilities001 stress test with sanity checking (+RTS -DS) turned on:

```
cd testsuite/tests/concurrent/should_run
make TEST=setnumcapabilities001 WAY=threaded1 EXTRA_HC_OPTS=-with-rtsopts=-DS CLEANUP=0
while true; do ./setnumcapabilities001.run/setnumcapabilities001 4 9 2000 || break; done
```

2. The test case from #12419

Reviewers: niteria, ezyang, rwbarton, austin, bgamari, erikd

Subscribers: thomie, ezyang

Differential Revision: https://phabricator.haskell.org/D2441

GHC Trac Issues: #12419
rts/Schedule.c