Disabling WPP

Emjayen

Is there an administrative toggle to disable WPP tracing? Or would this require recompilation of the driver (of which is not an option, as it's not mine)

The reasoning in this case being that a performance-critical path is tied up in WppAutoLogTrace, accounting for ~65% of time.

MBond2

WPP is designed to be lightweight. It would be a surprise if it represented a significant performance issue in a driver. WPP consumers can be enabled or disabled, but if a driver is a producer, then those calls can't be removed without building a new version

Emjayen

Figured as much; that's unfortunate. It certainly is the culprit in this instance however

A bit of hacking to remove the call-site also confirms it.

Dejan_Maksimovic

If WPP runs in a path that is CPU intemsive but small, it easily makes the
path underperforn.

Scott_Noone_(OSR)

Looks like this is the WPP Recorder. There are some per-driver settings that you can configure in the Registry:

https://learn.microsoft.com/en-us/windows-hardware/drivers/devtest/using-wpp-recorder

Maybe this driver is using an unusual configuration? Also, what's the perf scenario and how are you capturing the perf data?

MBond2

This looks like a partial screenshot from one of the Intel tools. If that's the case, then it is far from certain that the high CPU time you observe here is actually indicative of a performance problem CAUSED by this function. Your remark about hacking is more suggestive, but it is hard to know.

A pure guess is that you are testing some kind of network application, and you are looking at some kind of metric of single connection throughput. Its a pure guess, but it might fit the situation that you describe

Tim_Roberts

I'm not sure what you're trying to say here. Intel's performance analysis tools are among the best in the industry. If it suggests that 64% of CPU time is being spend in WppAutoLogTrace, then the reality is probably pretty darned close to that.

MBond2

I have worked with the Intel tools for many years - since from when they were new in the early 2000's. I don't doubt that the tool reports the correct value, and that 64% of the observed CPU time was taken by that function, but the question remains whether any of that CPU time actually contributed to a performance problem.

Assuming that these numbers come from hotspot or lightweight hotspot analysis, if the CPU has not been maxed out during the test, it is very likely that the thread context that this CPU usage happens in is irrelevant to the overall performance problem being investigated. The key is to look at the call stack views (top down / bottom up). We simply don't have enough information to provide useful suggestions

Dejan_Maksimovic

? If the path is a hotpath, any CPU usage decreases performance.

MBond2

But is the path a hot path? Hot spot analysis does not tell you that. Hot spot analysis tells you that user a certain sample frequency, the observed location of the IP of threads running on not idle cores was X. And for each number of times X was observed, or some other cut of the call stack, a percentage is derived.

if the observed location is at the bottom of a tight loop, or the system has been maxed out (CPU usage), then these metrics are reliable sources of performance problems. otherwise, they might be performance problems or incidental waste, or offloaded work that actually increases the performance of the critical path by moving work like logging onto otherwise idle cores / threads

fining out which callstack is a performance critical path is not so easy using these tools. If you already know which one is performance critical, then it is easy to filter out everything else and focus on the stalls that ordinarily or might occur along that path