Re: opreport on time window of operf data

Henry May <[email protected]>
Newsgroups gmane.linux.oprofile
Message-ID <OFA86F0C2B.0091D8FC-ON87257E12.004D855B-86257E12.004E3116@us.ibm.com>
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. 

> 
> 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/

_______________________________________________
oprofile-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oprofile-list
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.