[GHC] #8224: Excessive system time -- new IO manager problem?

[GHC]

#8224: Excessive system time -- new IO manager problem?
-------------------------------------+-------------------------------------
        Reporter:  rrnewton          |            Owner:
            Type:  bug               |           Status:  new
        Priority:  high              |        Milestone:  7.8.1
       Component:  Runtime System    |          Version:  7.7
      Resolution:                    |         Keywords:  IO Manager,
Operating System:  Linux             |  System Time
 Type of failure:  Runtime           |     Architecture:  x86_64 (amd64)
  performance bug                    |       Difficulty:  Unknown
       Test Case:                    |       Blocked By:
        Blocking:                    |  Related Tickets:
-------------------------------------+-------------------------------------

Comment (by AndreasVoellmy):

 I did some more experiments, and I now think it has to do with making
 "safe" foreign calls from all of the 32 threads.  I modified the IO
 manager so that all of the polling threads (and their epoll backends) are
 created. Only one of the them is used (on cap 0) is used to register
 files. I then modified the poll loops so that only the one on cap 0 is
 running the normal polling loop and the others simply return right away.
 With this setup, the performance is good (about 40-50 ms for -N32).
 However, if I have all poll loops (except the one normal poll loop for cap
 0) simply make a "safe" call to `usleep(10)` then the performance goes
 back to about 200ms.  I'll post a patch here so that others can see.

 So it looks to be related to the cost of doing safe foreign calls. With
 the parallel IO manager each of the N pollers will make a safe foreign
 call when there is no work to do. I'm not sure that this will have much of
 an impact on most programs, but for the empty program it represents a
 large part of the work.

 I'm also not sure this is related to the 8 minute system time mentioned in
 the original report.  rnewton, can you provide a recipe for how to
 recreate this?

 Is the 200 ms startup time for 32 cores an issue? At 16 cores it is about
 50-60ms and at 8 cores about 10-20ms.

 One possible resolution (besides doing nothing or making safe foreign
 calls cheaper) would be to provide an RTS option to use a specific number
 of IO managers, or at least to differentiate between using 1 or using N.

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