Another try to get thread migration right
authorSimon Marlow <marlowsd@gmail.com>
Thu, 4 Aug 2016 14:59:43 +0000 (15:59 +0100)
committerBen Gamari <ben@smart-cactus.org>
Thu, 25 Aug 2016 15:36:10 +0000 (11:36 -0400)
commit13ff3423e058a409b035acce5c1448237885ac84
tree342b460c59840a74db90aa01706420ee2d8061fd
parent9f1b6de8b3f788730fa5e2206fb709400299be7c
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

(cherry picked from commit 89fa4e968f47cfb42d0dc33fc3bfffdce31d850e)
rts/Schedule.c