dotnet-trace always detects 100% CPU usage

[alexeygritsenko]

Hello, I don’t know if my question is a bug or incorrect use of the utility, but the fact is that it always shows 100% load in reports when in fact it is not.

Steps:

1. check "top" command and see 0%-24%
2. run "dotnet-trace collect -p 1205 --duration 00:00:00:30" command and see report in VS2022, 100% always I would appreciate any help to fix this. I want accurate results.

System: 4 core + 8gb ram Ubuntu 20.04.5 LTS .net 6.0.12 sdk + runtime dotnet-trace 6.0.351802

[hoyosjs]

Feel free to correct me @davmason @dramos020 if this is not accurate. The main thing is the runtime emits the events that are used to calculate the stacks of running code

• Since the runtime has to stop the threads to walk them and send the even, there's a bias for GC safe points. This means it's very poorly suited right now for certain classes of behaviors (some classes of loops, some partially interruptible code, P/Invokes).
• It's emitted by and from the runtime's perspective - so all events are written from a "where's my execution at", more than the classic thread time view. Blocking OS calls and waiting primitives that don't consume CPU show up as an event. What you're looking for is the "Thread Time" view, and for that you need LTTNG and/or using the perfmap support. Both have some measurably high runtime perf hits, so they are better suited for ad-hoc investigations.

cc: @karpinsn

[tommcdon]

I added the documentation label as we should better document dotnet-trace "CPU" time is actually "Thread Time", and so if threads are blocked it will still report the time on that thread the same as CPU execution.

[alexeygritsenko]

Thank you for your responses! Now it is clear that this is not a bug but a nuance. What if make an "exclude" feature for VS viewer? (like as "Right click -> Exclude") Exclude specific namespaces from profiler results and recalculated with exclusions in mind, where we would have more precise results.

[davmason]

Hi @alexeygritsenko,

The issue here is we are reporting fundamentally different data (thread time vs CPU time), and there isn't a good way to massage it to act like CPU time. For any feature requests for VS, the right place to file them is https://developercommunity.visualstudio.com/VisualStudio

[romkatv]

The issue here is we are reporting fundamentally different data (thread time vs CPU time)

I found this out the hard way. I've migrated my code from Windows to Linux and thought I would be able to use dotnet-trace for CPU-profiling my code on Linux the same way I previously used VSPerf.exe on Windows. Unfortunately, dotnet-trace measures wall time, so the profile is dominated by sleeping threads: thread pool threads waiting for work, IO completion threads waiting for IO, various threads waiting on semaphores, etc.

What is the recommended way for collecting CPU profiles of dotnet applications on Linux?

P.S.

I'm sorry if I'm hijacking this issue. I can open another one if you prefer.