Process related performance monitoring

Hello again everyone,

my current task is to record (to write an app for recording) some performance measurements related to a subset of specific processes. Many values can be of interest, but most important are some programmable CPU performance counters such as those provided by the PMU. The task includes recording values of interest at the moments of process creation/shutdown, at context switching and maybe also at some interrupt occurrence moments. The target system is currently XP.

I know the system does not provide any callbacks for context switching, but before I start to brutishly patch-hook the kernel I wanted to ask if there’s a graceful and documented way to create the statistics. It’s important, that the statistics is recorded for each individual process of interest separately.

Have you looked at x-perf, which is now called WPT (Windows performance tool), to collect this data for you? There is certainly lots of this type of info accessible through xperf in later releases, restricting to XP is going to be quite limiting.

d

Bent from my phone


From: xxxxx@mailbox.tu-berlin.demailto:xxxxx
Sent: ?12/?7/?2013 9:45 AM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: [ntdev] Process related performance monitoring

Hello again everyone,

my current task is to record (to write an app for recording) some performance measurements related to a subset of specific processes. Many values can be of interest, but most important are some programmable CPU performance counters such as those provided by the PMU. The task includes recording values of interest at the moments of process creation/shutdown, at context switching and maybe also at some interrupt occurrence moments. The target system is currently XP.

I know the system does not provide any callbacks for context switching, but before I start to brutishly patch-hook the kernel I wanted to ask if there’s a graceful and documented way to create the statistics. It’s important, that the statistics is recorded for each individual process of interest separately.


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx></mailto:xxxxx>

I used it only once a couple of years ago (needed to find a cause of performance degradation in my system) and therefore didn’t have a precise look at it. I’m going to take a look at xperf and in the worst case it could be an option, but as long as performance monitoring is not the whole functionality of the required application, it’s very preferable to have available source codes of such an application. Besides, it’s important to have a maximum flexibility in the choice of performance counters provided by the hardware. I actually initially need to collect statistics for all of them.

So I assume, there’s no other way as hotpatching the kernel.

To: Doron Holan
Thank you for reminding me of the xperf.

Weeeeelllll… xperf is an application, that uses built-in Windows ETW trace points.

Perhaps you could write an app that ALSO uses these trace points?

I’ve done it, but it was a looong time ago. I can’t recall whether the information on how to do this is sufficiently documented to allow you to do anything useful.

Peter
OSR

To: Peter Viscarola (OSR)
Sounds creepy, but I’ll see what I can do. :slight_smile: I’m gonna use hotpatching for the PoC version of software. At least to be able to collect the statistics, as the deadlines are very close (as always), and then to do a bit of further research. Unfortunately, as they say, there’s nothing more persistent than temporary design decisions.

It’s actually incredibly slick, once you get it to work. You wind-up capitalizing on the internal trace-points in Windows and writing your own logger for that data… relatively low overhead and very flexible.

That’s understandable.

Before you do that, you might want to spend an hour in Google to see if there’s a sample that shows capturing the internal Windows trace data. Note that this is a user-mode API I’m talking about. It’ll save you a ton of time if so, and it’s just one of many trace points that are available.

IF you could get the trace data, the entire project could be done in user-mode… which is where this sort of thing really belongs, don’t you think?

too true… too true…

Peter
OSR