Allow modification of capabilities at runtime

[mlesniak]

Currently the number of capabilities can only be set at the start of a program using -N<n>. At least for benchmarking and playing with semi-implicit code (any other real-world scenarious?) if would be nice to change the number of capabilities at runtime.

[NeilMitchell]

This would be great so applications can implement -j3 flags internally, rather than relying on the user to write +RTS -N3 -RTS. The original requester seems to be thinking of developers, but this feature would be a massive benefit to end users of Haskell programmers.

[mlesniak]

As you can see  here, I'm currently "trying" to implement this. Since I'm quite new to GHC's development I'm a bit lost but fiddling my way around in my free time.

I'd be grateful to any pointers, links to documentation or blog post, etc...

- Michael

[simonmar]

See also #3210 - there should be a way to change the number of capabilities programmatically.

[simonmar]

See also #3989: reducing the number of capabilities dynamically when the machine is contended is probably a good idea.

[marlowsd@…]

commit 92e7d6c92fdd14de424524564376d3522f2a40cc

Author: Simon Marlow <marlowsd@gmail.com>
Date:   Tue Dec 6 15:12:07 2011 +0000

    Allow the number of capabilities to be increased at runtime (#3729)
    
    At present the number of capabilities can only be *increased*, not
    decreased.  The latter presents a few more challenges!

 docs/users_guide/using.xml |   14 +++-
 includes/rts/Threads.h     |   10 +++
 rts/Capability.c           |   66 ++++++++++++-----
 rts/Capability.h           |    6 ++-
 rts/Linker.c               |    1 +
 rts/Schedule.c             |  172 ++++++++++++++++++++++++++++++++++++--------
 rts/Stats.c                |    2 +-
 rts/Task.c                 |   28 +++++++
 rts/Task.h                 |    5 ++
 rts/Trace.c                |    7 ++
 rts/Trace.h                |    1 +
 rts/eventlog/EventLog.c    |   27 ++++++--
 rts/eventlog/EventLog.h    |    1 +
 rts/sm/GC.c                |   50 ++++++++-----
 rts/sm/GC.h                |    2 +-
 rts/sm/Storage.c           |   70 +++++++++++--------
 rts/sm/Storage.h           |    4 +
 17 files changed, 358 insertions(+), 108 deletions(-)

[simonmar]

commit 9bae79159d3cb5cbb6491711341aa9b07d703ae6

Author: Simon Marlow <marlowsd@gmail.com>
Date:   Tue Dec 13 13:09:46 2011 +0000

    Support for reducing the number of Capabilities with setNumCapabilities
    
    This patch allows setNumCapabilities to /reduce/ the number of active
    capabilities as well as increase it.  This is particularly tricky to
    do, because a Capability is a large data structure and ties into the
    rest of the system in many ways.  Trying to clean it all up would be
    extremely error prone.
    
    So instead, the solution is to mark the extra capabilities as
    "disabled".  This has the following consequences:
    
      - threads on a disabled capability are migrated away by the
        scheduler loop
    
      - disabled capabilities do not participate in GC
        (see scheduleDoGC())
    
      - No spark threads are created on this capability
        (see scheduleActivateSpark())
    
      - We do not attempt to migrate threads *to* a disabled
        capability (see schedulePushWork()).
    
    So a disabled capability should do no work, and does not participate
    in GC, although it remains alive in other respects.  For example, a
    blocked thread might wake up on a disabled capability, and it will get
    quickly migrated to a live capability.  A disabled capability can
    still initiate GC if necessary.  Indeed, it turns out to be hard to
    migrate bound threads, so we wait until the next GC to do this (see
    comments for details).