perf报告多条目耗时占比超90%的矛盾问题咨询

Hey there, this is a classic misunderstanding with how perf calculates time when you enable call graphs (-g). Let's unpack this step by step:

The Core Issue: Inclusive vs. Exclusive Time #

By default, perf report shows inclusive time for each function when call graphs are enabled. This isn't just the time the function itself spends executing—it's the total time of the function plus every single function it calls (all the way down the call stack).

For example:

• If your process spends 95% of its time inside java_start, then any function that calls java_start (like start_thread, or even higher-level kernel entry points) will have an inclusive time of ~95% too. Because their call stacks include the time spent in java_start.
• It's not that the process is running both functions simultaneously—it's that the upper-level functions "own" all the time spent in their subtree of the call graph.

How to See the "Real" Per-Function Time #

To get the actual time each function spends executing on its own (excluding child calls), you need to switch to exclusive time view:

• Run perf report with the --exclusive flag: perf report -g exclusive -p <pid>
• Or if you're already in the interactive perf report interface, press the E key to toggle between inclusive and exclusive time.

With exclusive time, you'll see the percentages add up to ~100%, and you'll clearly see which function is actually eating up the most CPU on its own.

Other Edge Cases to Consider #

While inclusive time is the most common culprit, here are a few other things to check:

• Sampling bias: If your sampling frequency is too low or too high, you might get skewed results. Stick to the default frequency (usually 99Hz) unless you have a specific reason to adjust it.
• Kernel vs. user space: Make sure you're filtering the view to user-space functions if that's what you care about (press K in interactive mode to toggle kernel symbols on/off).

内容的提问来源于stack exchange，提问作者J. Doe