From: Michael R. <mj...@ca...> - 2013-12-14 18:52:05
|
Might I enquire whether there is any progress on fixing the "spurious recursion" issue with oprofile ( http://marc.info/?l=oprofile-list&m=138264317624196&w=2 and http://sourceforge.net/p/oprofile/bugs/256/ ). I was planning to give a seminar describing, amongst other things, operf's very useful ability to capture call chains whilst profiling. As the data it currently produces require a non-obvious interpretation, I am considering talking about something else instead! Regards, Michael Rutter |
From: Maynard J. <may...@us...> - 2013-12-16 15:35:58
|
On 12/14/2013 12:30 PM, Michael Rutter wrote: > Might I enquire whether there is any progress on fixing the "spurious > recursion" issue with oprofile ( > http://marc.info/?l=oprofile-list&m=138264317624196&w=2 and > http://sourceforge.net/p/oprofile/bugs/256/ ). I was planning to give a > seminar describing, amongst other things, operf's very useful ability > to capture call chains whilst profiling. As the data it currently > produces require a non-obvious interpretation, I am considering talking > about something else instead! Michael, Thanks for the gentle nag. I've had a patch in my back pocket for this issue for a while, but wasn't 100% happy with it. But I'm not sure there's a way to make it perfect. So I'd appreciate some feedback from both you and *David* (and anyone else) on the fix, which I attached to the bug (https://sourceforge.net/p/oprofile/bugs/256/). -Maynard > > Regards, > > Michael Rutter > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > _______________________________________________ > oprofile-list mailing list > opr...@li... > https://lists.sourceforge.net/lists/listinfo/oprofile-list > |
From: Maynard J. <may...@us...> - 2013-12-19 17:26:24
|
On 12/16/2013 09:35 AM, Maynard Johnson wrote: > On 12/14/2013 12:30 PM, Michael Rutter wrote: >> Might I enquire whether there is any progress on fixing the "spurious >> recursion" issue with oprofile ( >> http://marc.info/?l=oprofile-list&m=138264317624196&w=2 and >> http://sourceforge.net/p/oprofile/bugs/256/ ). I was planning to give a >> seminar describing, amongst other things, operf's very useful ability >> to capture call chains whilst profiling. As the data it currently >> produces require a non-obvious interpretation, I am considering talking >> about something else instead! > Michael, > Thanks for the gentle nag. I've had a patch in my back pocket for this issue for a while, but wasn't 100% happy with it. But I'm not sure there's a way to make it perfect. So I'd appreciate some feedback from both you and *David* (and anyone else) on the fix, which I attached to the bug (https://sourceforge.net/p/oprofile/bugs/256/). David, In a different posting thread, Michael Rutter already gave me some positive feedback on this "false recursion" patch. I would appreciate if you could run with this patch, too, to make sure it addresses your original issue. BTW, I've done some further testing using a testcase that does actual recursion and, contrary to my earlier supposition, there was no loss of information even when the samples occur at the point of recursion. And thinking on it a bit more, I don't know why I thought there would be, since my patch only removes the first callchain entry, which by definition (from the kernel's behavior) is a duplicate of the sampled address. Note: There is an unnecessary and unused variable in the patch (bool tab = false;), which I'll remove before committing. -Maynard > > -Maynard >> >> Regards, >> >> Michael Rutter >> >> ------------------------------------------------------------------------------ >> Rapidly troubleshoot problems before they affect your business. Most IT >> organizations don't have a clear picture of how application performance >> affects their revenue. With AppDynamics, you get 100% visibility into your >> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! >> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk >> _______________________________________________ >> oprofile-list mailing list >> opr...@li... >> https://lists.sourceforge.net/lists/listinfo/oprofile-list >> > > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > _______________________________________________ > oprofile-list mailing list > opr...@li... > https://lists.sourceforge.net/lists/listinfo/oprofile-list > |
From: David F. <df...@ni...> - 2013-12-23 15:50:42
|
<html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </head> <body text="#000000" bgcolor="#FFFFFF"> <div class="moz-cite-prefix">On 12/19/2013 12:26 PM, Maynard Johnson wrote:<br> </div> <blockquote class=" cite" id="mid_52B32C36_6090005_us_ibm_com" cite="mid:52B...@us..." type="cite">David, In a different posting thread, Michael Rutter already gave me some positive feedback on this "false recursion" patch. I would appreciate if you could run with this patch, too, to make sure it addresses your original issue.</blockquote> <br> On the simple test case that reproduced the failure, it does make the failure go away. I have not tested extensively to determine if there was any collateral damage. My only question about the patch would be if anyone has inspected the implementation of perf in the tools/perf subdirectory of the Linux kernel source tree to determine how perf itself deals with the duplicated addresses.<br> <br> <div class="moz-signature">-- <br> David Flater, National Institute of Standards and Technology, U.S.A. </div> <br> </body> </html> |
From: Maynard J. <may...@us...> - 2014-01-02 14:57:18
|
On 12/23/2013 09:38 AM, David Flater wrote: > On 12/19/2013 12:26 PM, Maynard Johnson wrote: >> David, In a different posting thread, Michael Rutter already gave me some positive feedback on this "false recursion" patch. I would appreciate if you could run with this patch, too, to make sure it addresses your original issue. > > On the simple test case that reproduced the failure, it does make the failure go away. I have not tested extensively to determine if there was any collateral damage. My only question about the patch would be if anyone has inspected the implementation of perf in the tools/perf subdirectory of the Linux kernel source tree to determine how perf itself deals with the duplicated addresses. Thanks for testing, David. I've pushed the patch to oprofile's upstream repo. As for perf, that's outside of my scope. You can post to the linux-perf-users mailing list to pursue a change in perf. -Maynard > > -- > David Flater, National Institute of Standards and Technology, U.S.A. > |
From: David F. <df...@ni...> - 2014-01-02 15:07:21
|
<html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </head> <body text="#000000" bgcolor="#FFFFFF"> <div class="moz-cite-prefix">On 1/2/2014 9:57 AM, Maynard Johnson wrote:<br> </div> <blockquote class=" cite" id="mid_52C57E42_6030604_us_ibm_com" cite="mid:52C...@us..." type="cite"> <pre wrap="">On 12/23/2013 09:38 AM, David Flater wrote: </pre> <blockquote class=" cite" id="Cite_7449571" type="cite"> <pre wrap="">On 12/19/2013 12:26 PM, Maynard Johnson wrote: </pre> <blockquote class=" cite" id="Cite_2567786" type="cite"> <pre wrap="">David, In a different posting thread, Michael Rutter already gave me some positive feedback on this "false recursion" patch. I would appreciate if you could run with this patch, too, to make sure it addresses your original issue. </pre> </blockquote> <pre wrap="">On the simple test case that reproduced the failure, it does make the failure go away. I have not tested extensively to determine if there was any collateral damage. My only question about the patch would be if anyone has inspected the implementation of perf in the tools/perf subdirectory of the Linux kernel source tree to determine how perf itself deals with the duplicated addresses. </pre> </blockquote> <pre wrap="">Thanks for testing, David. I've pushed the patch to oprofile's upstream repo. As for perf, that's outside of my scope. You can post to the linux-perf-users mailing list to pursue a change in perf.</pre> </blockquote> <br> Perf has never exhibited the spurious recursion problem that occurred with operf. What I intended to suggest was that the author of the patch could examine the source code of perf to determine what perf does with the apparently duplicated addresses. The information thus gleaned about the usage of the perf infrastructure may suggest a different resolution than what was implemented in the operf patch.<br> <br> <div class="moz-signature">-- <br> David Flater, National Institute of Standards and Technology, U.S.A. </div> <br> </body> </html> |
From: Maynard J. <may...@us...> - 2014-01-02 17:26:19
|
On 01/02/2014 09:06 AM, David Flater wrote: > On 1/2/2014 9:57 AM, Maynard Johnson wrote: >> On 12/23/2013 09:38 AM, David Flater wrote: >>> On 12/19/2013 12:26 PM, Maynard Johnson wrote: >>>> David, In a different posting thread, Michael Rutter already gave me some positive feedback on this "false recursion" patch. I would appreciate if you could run with this patch, too, to make sure it addresses your original issue. >>> On the simple test case that reproduced the failure, it does make the failure go away. I have not tested extensively to determine if there was any collateral damage. My only question about the patch would be if anyone has inspected the implementation of perf in the tools/perf subdirectory of the Linux kernel source tree to determine how perf itself deals with the duplicated addresses. >> Thanks for testing, David. I've pushed the patch to oprofile's upstream repo. As for perf, that's outside of my scope. You can post to the linux-perf-users mailing list to pursue a change in perf. > > Perf has never exhibited the spurious recursion problem that occurred with operf. Well, actually, it does -- sort of. It's just not so glaringly obvious. Using the same non-recursive testcase as I used to demonstrate the operf/opreport issue in https://sourceforge.net/p/oprofile/bugs/256/, we see the following output from 'perf report' (after collecting a callgraph profile with 'perf record') on a RHEL 6.4/Intel platform: 5.94% memcpyt memcpyt [.] do_my_memcpy | --- do_my_memcpy main __libc_start_main The first line indicates that 5.95% of the samples were taken in the 'do_my_memcpy' function (function of focus). The lines below that indicate the callchain, and as you can see, 'do_my_memcpy' is at the top of the list. You may consider this output as correct, but only if you think that the callchain lines *should* include the function of focus ('do_my_memcpy' in this case). If this output format is good for you, then there's no perf issue to report. So, you may wonder why does opreport show the glaringly obvious false recursion you initially reported? This is due to the way that opreport processes a profile. The intention of the operf tool is to generate sample data files that are formatted identically to those created by the legacy (opcontrol-based) oprofile, so that opreport can work properly with profiles generated by either operf or legacy oprofile. Since the legacy oprofile kernel driver did *not* include the sampled address in the callchain, we need this patch in operf to strip that sampled address out. I hope that clears things up. -Maynard > What I intended to suggest was that the author of the patch could examine the source code of perf to determine what perf does with the apparently duplicated addresses. The information thus gleaned about the usage of the perf infrastructure may suggest a different resolution than what was implemented in the operf patch. > > -- > David Flater, National Institute of Standards and Technology, U.S.A. > |