<div dir="ltr"><div>Ben,</div><div><br></div>I could reproduce it even after removing all FFI calls. I created a ghc trac ticket, you can find it here: <a href="https://ghc.haskell.org/trac/ghc/ticket/14445">https://ghc.haskell.org/trac/ghc/ticket/14445</a>. Let me know if any more information is needed or if explanation about the code/repo is required.<div><br></div><div>Thanks,</div><div>Harendra<br><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 10 November 2017 at 00:12, Harendra Kumar <span dir="ltr"><<a href="mailto:harendra.kumar@gmail.com" target="_blank">harendra.kumar@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Ben,<div><br></div>Yes, there are FFI calls between the two getRTSStats calls. FFI calls are C APIs to get some OS stats like clock time or cpu time etc. Now I know that this is not expected, let me try to minimize the example and see where it goes. I will try removing the FFI calls as well.<span class="HOEnZb"><font color="#888888"><div><br></div><div>-harendra</div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On 9 November 2017 at 23:49, Ben Gamari <span dir="ltr"><<a href="mailto:ben@well-typed.com" target="_blank">ben@well-typed.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>Harendra Kumar <<a href="mailto:harendra.kumar@gmail.com" target="_blank">harendra.kumar@gmail.com</a>> writes:<br>
<br>
> Hi,<br>
><br>
> I am trying to use the mutator_cpu_ns and mutator_elapsed_ns from GHC 8.2<br>
> RTSStats structure retrieved using getRTSStats API documented here -<br>
> <a href="https://hackage.haskell.org/package/base-4.10.0.0/docs/GHC-Stats.html" rel="noreferrer" target="_blank">https://hackage.haskell.org/pa<wbr>ckage/base-4.10.0.0/docs/GHC-<wbr>Stats.html</a> .<br>
><br>
> I am seeing that the values of these stats retrieved about 30 ms later are<br>
> lower than the values retrieved earlier. Sometimes even after 100 ms the<br>
> values decrease from the previous ones. However, as the time duration<br>
> between two calls increase this becomes less and less likely.<br>
><br>
> Is this an expected behavior or am I using it incorrectly? If it is<br>
> expected, why does it happen, what is the underlying mechanism that makes<br>
> it happen?<br>
><br>
</span>Hmm, interesting. I don't believe this should happen and I do know of<br>
bugs in the RTS's time accounting at exit-time (manifesting in profiling<br>
issues, e.g. #14257) however what you describe doesn't seem to fit that<br>
description. Do you have a simple repro? Is there anything special about<br>
your program (e.g. lots of FFI calls)?<br>
<br>
Cheers,<br>
<br>
- Ben<br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>