Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results
The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.
Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/
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.
|Upcoming OSR Seminars|
|OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!|
|Kernel Debugging||30 January 2023||Live, Online|
|Developing Minifilters||20 March 2023||Live, Online|
|Internals & Software Drivers||17 April 2023||Live, Online|
|Writing WDF Drivers||22 May 2023||Live, Online|
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
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.
Looks like this is the WPP Recorder. There are some per-driver settings that you can configure in the Registry:
Maybe this driver is using an unusual configuration? Also, what's the perf scenario and how are you capturing the perf data?
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
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.
Tim Roberts, [email protected]
Providenza & Boekelheide, Inc.
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
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