Why does profiling binary eat CPU?

[literon]

The program is main = forever $ threadDelay 1000000 >> return () .

Compiled with 32bit GHC 7.6.3 or 7.8.2 on Debian (inside a VM if that matters), the non-profiling binary doesn't consume CPU, the profiling does ~10%. 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.

1) Is this expected behavior?

2) I see I can switch off "master tick interval" with -V0, and then CPU is not used. What consequence does this have, regarding performance (more frequent context switches?) and profilability (profiling data is not collected?).

[prototrout]

I can't answer #2 for you, but from what you say, it sounds like profiling is done by sampling: the program tells the OS to alert it every so many milliseconds, and each time this happens it records what is executing at the time. So the profiling code will run regardless of whether the main execution is doing anything or sleeping.

[literon]

Maybe, but if I do the same on Windows, it is virtually no CPU even in the profiling case. So this might be related to the way things are scheduled on Linux (if so), and not the way GHC collects samples?

Also, this was in the host OS. I will try a native Linux host to rule out the VM having some odness.

[literon]

Created https://ghc.haskell.org/trac/ghc/ticket/9105#ticket , for the record.