[GHC] #9105: Profiling binary consumes CPU even when idle on Linux.

[GHC]

#9105: Profiling binary consumes CPU even when idle on Linux.
-------------------------------------+-------------------------------------
        Reporter:  robinp            |                Owner:  simonmar
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Runtime System    |              Version:  7.8.2
      Resolution:                    |             Keywords:
Operating System:  Linux             |         Architecture:  x86
 Type of failure:  Runtime           |            Test Case:
  performance bug                    |
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

@@ -2,2 +2,6 @@
-   main = forever $ threadDelay 1000000 >> return () .
-
+ {{{#!hs
+ import Control.Concurrent
+ import Control.Monad (forever)
+ main :: IO ()
+ main = forever $ threadDelay 1000000 >> return ()
+ }}}
@@ -7,1 +11,1 @@
- a 2Ghz machine). Running with +RTS -I0, so this is not the idle gc.
+ a 2Ghz machine). Running with `+RTS -I0`, so this is not the idle gc.
@@ -12,1 +16,1 @@
- I see I can switch off "master tick interval" with -V0, and then CPU is
+ I see I can switch off "master tick interval" with `-V0`, and then CPU is
@@ -17,1 +21,1 @@
- platform, 64bit), it doesn't use more CPU than the non-profiling.
+ platform, 64-bit), it doesn't use more CPU than the non-profiling.

New description:

 The program is
 {{{#!hs
 import Control.Concurrent
 import Control.Monad (forever)
 main :: IO ()
 main = forever $ threadDelay 1000000 >> return ()
 }}}
 Compiled with 32bit GHC 7.6.3 or 7.8.2 on Debian (inside a VM), GHC 7.4.1
 on Ubuntu (not VM).
 The non-profiling binary doesn't consume CPU, the profiling does ~10% (of
 a 2Ghz machine). Running with `+RTS -I0`, so this is not the idle gc.

 When strace-ing, the profiling one seems to receive a constant flow of
 SIGVTALRM, while the normal receives one burst each second.

 I see I can switch off "master tick interval" with `-V0`, and then CPU is
 not used, but the consequences of this are not very well documented (apart
 from context switching becoming deterministic).

 Interestingly, if I compile using profiling on Windows (latest haskell-
 platform, 64-bit), it doesn't use more CPU than the non-profiling.

 So, the question is, why does this happen on Linux, and if it can be
 avoided somehow.

--

Comment (by bgamari):

 If I'm not mistaken this is an expected result of our profiler, which is a
 sampling profiler. Looking at a `perf` profile reveals that this CPU time
 is largely spent in `handle_tick`. Diving in here we find that the first
 thing this function does is call `handleProfTick`, which does a variety of
 book-keeping to schedule the next time/heap sample.

 There is yet another difference, however: in the non-profiling case the
 tick timer is stopped when the process is known to be idle. In the
 profiling case we can't do this, to ensure that our profile isn't skewed.
 However, I believe it would be safe to nevertheless disable the compiler
 if you didn't run the executable with `+RTS -h` or `+RTS -p`. This is
 probably something that we should do.

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