On 08/28/2012 09:47 AM, Avi Gozlan wrote:
> Based on a very first investigation, it seems to me that this does not concern only the user mode OProfile package, rather involves also the OProfile kernel module (e.g. add a time interval in a file in /dev/oprofile and modify the kernel to behave accordingly). If this is the case, it makes the whole thing more complex. Am I correct or am I missing something?
hrmmm . . . For something more accurate than wall-clock time (as you said in your initial note, perhaps based on scheduling), you're right -- a lot more complex than just oprofile stopping after some designated time. It would be possible to pass a time value and a process ID to the oprofile kernel driver and have it enable/disable profiling when the given process context switches in or out. But pushing such changes upstream would be a hard sell. The oprofile kernel driver is more or less deprecated in favor of the Linux kernel Performance Events Subsystem (aka "perf_events"). As a matter of fact, the latest release of oprofile (0.9.8, just released yesterday), includes a program called 'operf' which uses perf_events for profiling instead of the oprofile kernel driver. The opcontrol-based mechanism (using the kernel driver) is still available, but it will eventually be removed.
> Is there any document describing the architecture of the OProfile kernel module? Appropriate methodology (e.g. whether to use interrupt for stopping sampling upon expiry of time interval, how to maintain backward compatibility for older OProfile packages etc.)? I'm not sure I would have the time to implement this, yet in case I would, your answer would be an important reference.the You might find our "OProfile Internals" documentation helpful (http://oprofile.sourceforge.net/doc/internals/index.html) to understand how the opcontrol/kernel driver mechanism works. But a good study of the kernel driver source code would be most helpful if you decide to pursue enhancing oprofile (if even just for a private build). On the other hand, you might get the result you want quicker and easier by using SystemTap. I'm not real well-versed with SystemTap, but there is a SystemTap probe for context switches. On my RHEL 6.3 installation, there's an example of using it located in:
which is included in the systemtap-client package. You could perhaps write a stap script that would use opcontrol start/stop on context switch in/context switch out. As context switches become more frequent, though, the latencies of the opcontrol start/stop commands would likely accumulate enough to be more than can be ignored. Also, if the application is multi-threaded or does fork/execs, I have no idea how well SystemTap may handle that.
> -----Original Message-----
> From: Maynard Johnson [mailto:maynardj@...]
> Sent: Monday, August 27, 2012 8:17 PM
> To: Avi Gozlan
> Cc: oprofile-list@...
> Subject: Re: Sampling for definite amount of time
> On 08/26/2012 03:27 AM, Avi Gozlan wrote:
>> When analyzing performance, it's quite simple to compare two different runs when benchmark is a controllable closed task. Yet, this is not always the case. For example, when load is steady and continuous, as far as I understand, one should collect samples for a definite amount of time for creating comparable measures.
>> I'm looking for a way to instruct OProfile work in such a way. A possible solution might be to create a script that starts sampling, then stops X microseconds later. Yet this assumes the OS to perform exactly as expected. Experience shows this is not reliable enough to due scheduling issues.
>> Is there any way to control sampling timing accurately in OProfile?
> No, but I'd be happy to review a patch if you'd like to propose something (e.g., a new "--profile-time" option for operf). A main design goal of operf is to keep the interface simple, so just a forewarning . . . I would not be in favor of adding new options unless there's some notable community support.
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond.
>> Discussions will include endpoint security, mobile security and the
>> latest in malware threats.
>> oprofile-list mailing list
> Scanned by Check Point Total Security Gateway.