Re: opreport on time window of operf data

On 03/24/2015 10:14 AM, Henry May wrote:
> 
> 
> 
> William Cohen <[email protected]> wrote on 03/24/2015 08:56:48 AM:
> 
>> From: William Cohen <[email protected]>
>> To: Henry May/Rochester/IBM@IBMUS, [email protected]
>> Date: 03/24/2015 08:57 AM
>> Subject: Re: opreport on time window of operf data
>>
>> On 03/23/2015 08:24 AM, Henry May wrote:
>> > Is there a way to make opreport only process events that occurred
>> in a subset window of the total operf collection time?  I have a
>> long running workload that occasionally sees a spike in L2 misses.  
>> I can determine when this happens because throughput drops.  I'd
>> like to profile the workload, but only consider events that fall
>> within the window of decreased throughput when generating the opreport.
>> >
>> >
>>
>> Hi Henry,
>>
>> operf doesn't have a convenient mechanism to control when the data
>> is collected.  If operf is collecting data for a process that is
>> spawned by operf, it will collect data for the lifetime of the
>> child.  As a kludge you might get a smaller duration measurement by
>> having operf attach to the currently running process with  "--pid
>> <pid>" option when the dip in throughput starts and then interrupt
>> operf with ctl-c or "kill -2 <operf_pid>" when want to stop data collection.
> Thanks Will.  I don't think I expressed my thinking clearly.  The feature I want would actually be on opreport.  I want operf to collect over the entire long interval. Then after identifying the shorter subset interval where throughput drops I would specify the start and end times on opreport - maybe something like:
> 
> opreport --start-time=<subset start> --stop-time=<subset end>
> 
> opreport would generate the histogram, but only include the profiling events that fall in the specified subset interval.

Hi Henry,

When recording data operf is discarding the time information and putting the data into histograms based on instruction pointer values, so opreport is not going to be able limit the analysis by time. This is due to the design to allow oprofile to collect data for long periods of time and didn't want the data files to keep growing because each sample was kept.  The down side of this is that it limits the time-based analysis.

Linux "perf record" is designed to run for limited periods of time.  It keeps a log of all the sample and the time order information around.  However, it doesn't appear that "perf report" has a way of specifying a time range to do the analysis on.

-Will


> 
>>
>> A couple other possible things that might affect L2 performance are
>> other processes polluting/invalidating the cache and the task being
>> migrated between processors.
>>
>> -Will
>>  
>> > Henry May
>> > IBM InfoSphere Streams Performance
>> > [email protected]
>> > 720-342-8873
>> > Tie: 963-8873
>> >
>> >
>> >
>> ------------------------------------------------------------------------------
>> > Dive into the World of Parallel Programming The Go Parallel
>> Website, sponsored
>> > by Intel and developed in partnership with Slashdot Media, is your
>> hub for all
>> > things parallel software development, from weekly thought
>> leadership blogs to
>> > news, videos, case studies, tutorials and more. Take a look and join the
>> > conversation now. http://goparallel.sourceforge.net/
>> >
>> >
>> >
>> > _______________________________________________
>> > oprofile-list mailing list
>> > [email protected]
>> > https://lists.sourceforge.net/lists/listinfo/oprofile-list
>> >
>>


------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/