* [BUG] perf report: different reports when run on terminal as opposed to script @ 2012-10-29 16:01 Dhaval Giani 2012-10-29 16:45 ` Dhaval Giani 0 siblings, 1 reply; 6+ messages in thread From: Dhaval Giani @ 2012-10-29 16:01 UTC (permalink / raw) To: Arnaldo de Melo, mingo, Peter Zijlstra, namhyung; +Cc: akshay kumar, LKML Hi, As part of a class assignment I have to collect some performance statistics. In order to do so I run perf record -g <the program I have to profile> And in another window, I start 200 threads of the load generator (which is not recorded by perf) This generates me statistics that I expect to see, and I am happy. As this is academia and a class assignment, I need to collect information and analyze it across different setups. Which of course meant I script this whole thing, which basically is for i in all possibilities do perf record -g <the program I have to profile> & WAITPID=$! for j in NR_THREADS do <start load generator> & KILLPID=$! done wait $PID kill $KILLPID mv perf.data results/perf.data.$i done (This is basic pseudo script of what I am doing), which results me having my profile being topped by _vscanf() and the function which I was seeing dominating in the older report dropping down to something like 5% (as opposed to 16-17%) Have I misunderstood how perf works? Something deeper? I am currently on 3.6.3. I can update to the latest upstream and report back. Any debug code is very welcome. I can also make my toy program and the scripts available for you to try out. Thanks! Dhaval ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [BUG] perf report: different reports when run on terminal as opposed to script 2012-10-29 16:01 [BUG] perf report: different reports when run on terminal as opposed to script Dhaval Giani @ 2012-10-29 16:45 ` Dhaval Giani 2012-10-30 7:42 ` Namhyung Kim 0 siblings, 1 reply; 6+ messages in thread From: Dhaval Giani @ 2012-10-29 16:45 UTC (permalink / raw) To: Arnaldo de Melo, mingo, Peter Zijlstra, namhyung; +Cc: akshay kumar, LKML On Mon, Oct 29, 2012 at 12:01 PM, Dhaval Giani <dhaval.giani@gmail.com> wrote: > Hi, > > As part of a class assignment I have to collect some performance > statistics. In order to do so I run > > perf record -g <the program I have to profile> > > And in another window, I start 200 threads of the load generator > (which is not recorded by perf) > > This generates me statistics that I expect to see, and I am happy. As > this is academia and a class assignment, I need to collect information > and analyze it across different setups. Which of course meant I script > this whole thing, which basically is > > for i in all possibilities > do > perf record -g <the program I have to profile> & > WAITPID=$! > for j in NR_THREADS > do > <start load generator> & > KILLPID=$! > done > wait $PID > kill $KILLPID > mv perf.data results/perf.data.$i > done > > (This is basic pseudo script of what I am doing), which results me > having my profile being topped by _vscanf() and the function which I > was seeing dominating in the older report dropping down to something > like 5% (as opposed to 16-17%) > > Have I misunderstood how perf works? Something deeper? I am currently > on 3.6.3. I can update to the latest upstream and report back. Any > debug code is very welcome. I can also make my toy program and the > scripts available for you to try out. I just updated to 6b0cb4eef7bdaa27b8021ea81813fba330a2d94d and I still see this happen. Thanks! Dhaval ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [BUG] perf report: different reports when run on terminal as opposed to script 2012-10-29 16:45 ` Dhaval Giani @ 2012-10-30 7:42 ` Namhyung Kim 2012-10-30 12:05 ` Dhaval Giani 0 siblings, 1 reply; 6+ messages in thread From: Namhyung Kim @ 2012-10-30 7:42 UTC (permalink / raw) To: Dhaval Giani; +Cc: Arnaldo de Melo, mingo, Peter Zijlstra, akshay kumar, LKML Hi Dhaval, On Mon, 29 Oct 2012 12:45:53 -0400, Dhaval Giani wrote: > On Mon, Oct 29, 2012 at 12:01 PM, Dhaval Giani <dhaval.giani@gmail.com> wrote: >> Hi, >> >> As part of a class assignment I have to collect some performance >> statistics. In order to do so I run >> >> perf record -g <the program I have to profile> >> >> And in another window, I start 200 threads of the load generator >> (which is not recorded by perf) >> >> This generates me statistics that I expect to see, and I am happy. As >> this is academia and a class assignment, I need to collect information >> and analyze it across different setups. Which of course meant I script >> this whole thing, which basically is >> >> for i in all possibilities >> do >> perf record -g <the program I have to profile> & >> WAITPID=$! >> for j in NR_THREADS >> do >> <start load generator> & >> KILLPID=$! >> done >> wait $PID You meant $WAITPID, right? >> kill $KILLPID Doesn't it kill the last load generator only? >> mv perf.data results/perf.data.$i >> done >> >> (This is basic pseudo script of what I am doing), which results me >> having my profile being topped by _vscanf() and the function which I >> was seeing dominating in the older report dropping down to something >> like 5% (as opposed to 16-17%) >> >> Have I misunderstood how perf works? Something deeper? I am currently >> on 3.6.3. I can update to the latest upstream and report back. Any >> debug code is very welcome. I can also make my toy program and the >> scripts available for you to try out. > > I just updated to 6b0cb4eef7bdaa27b8021ea81813fba330a2d94d and I still > see this happen. > > Thanks! > Dhaval ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [BUG] perf report: different reports when run on terminal as opposed to script 2012-10-30 7:42 ` Namhyung Kim @ 2012-10-30 12:05 ` Dhaval Giani 2012-10-31 7:12 ` Namhyung Kim 0 siblings, 1 reply; 6+ messages in thread From: Dhaval Giani @ 2012-10-30 12:05 UTC (permalink / raw) To: Namhyung Kim; +Cc: Arnaldo de Melo, mingo, Peter Zijlstra, akshay kumar, LKML On Tue, Oct 30, 2012 at 3:42 AM, Namhyung Kim <namhyung@kernel.org> wrote: > Hi Dhaval, > > On Mon, 29 Oct 2012 12:45:53 -0400, Dhaval Giani wrote: >> On Mon, Oct 29, 2012 at 12:01 PM, Dhaval Giani <dhaval.giani@gmail.com> wrote: >>> Hi, >>> >>> As part of a class assignment I have to collect some performance >>> statistics. In order to do so I run >>> >>> perf record -g <the program I have to profile> >>> >>> And in another window, I start 200 threads of the load generator >>> (which is not recorded by perf) >>> >>> This generates me statistics that I expect to see, and I am happy. As >>> this is academia and a class assignment, I need to collect information >>> and analyze it across different setups. Which of course meant I script >>> this whole thing, which basically is >>> >>> for i in all possibilities >>> do >>> perf record -g <the program I have to profile> & >>> WAITPID=$! >>> for j in NR_THREADS >>> do >>> <start load generator> & >>> KILLPID=$! >>> done >>> wait $PID > > You meant $WAITPID, right? > yes. grrr. I changed the name here to WAITPID for it to be clear and that was a fail. (I blame the cold) > >>> kill $KILLPID > > Doesn't it kill the last load generator only? > > Well, this was a bug in me typing the pseudo code. the actual script does "$KILLPID $!" Dhaval ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [BUG] perf report: different reports when run on terminal as opposed to script 2012-10-30 12:05 ` Dhaval Giani @ 2012-10-31 7:12 ` Namhyung Kim 2012-10-31 22:15 ` Dhaval Giani 0 siblings, 1 reply; 6+ messages in thread From: Namhyung Kim @ 2012-10-31 7:12 UTC (permalink / raw) To: Dhaval Giani; +Cc: Arnaldo de Melo, mingo, Peter Zijlstra, akshay kumar, LKML On Tue, 30 Oct 2012 08:05:45 -0400, Dhaval Giani wrote: > On Tue, Oct 30, 2012 at 3:42 AM, Namhyung Kim <namhyung@kernel.org> wrote: >> Hi Dhaval, >> >> On Mon, 29 Oct 2012 12:45:53 -0400, Dhaval Giani wrote: >>> On Mon, Oct 29, 2012 at 12:01 PM, Dhaval Giani <dhaval.giani@gmail.com> wrote: >>>> Hi, >>>> >>>> As part of a class assignment I have to collect some performance >>>> statistics. In order to do so I run >>>> >>>> perf record -g <the program I have to profile> >>>> >>>> And in another window, I start 200 threads of the load generator >>>> (which is not recorded by perf) >>>> >>>> This generates me statistics that I expect to see, and I am happy. As >>>> this is academia and a class assignment, I need to collect information >>>> and analyze it across different setups. Which of course meant I script >>>> this whole thing, which basically is >>>> >>>> for i in all possibilities >>>> do >>>> perf record -g <the program I have to profile> & >>>> WAITPID=$! >>>> for j in NR_THREADS >>>> do >>>> <start load generator> & >>>> KILLPID=$! >>>> done >>>> wait $PID >> >> You meant $WAITPID, right? >> > > yes. grrr. I changed the name here to WAITPID for it to be clear and > that was a fail. (I blame the cold) > >> >>>> kill $KILLPID >> >> Doesn't it kill the last load generator only? >> >> > > Well, this was a bug in me typing the pseudo code. the actual script > does "$KILLPID $!" Okay, so I suspect that it might be affected by the autogroup scheduling feature since you said running load generators in another window - I guess it's a terminal. How about running them with setsid? Thanks, Namhyung ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [BUG] perf report: different reports when run on terminal as opposed to script 2012-10-31 7:12 ` Namhyung Kim @ 2012-10-31 22:15 ` Dhaval Giani 0 siblings, 0 replies; 6+ messages in thread From: Dhaval Giani @ 2012-10-31 22:15 UTC (permalink / raw) To: Namhyung Kim; +Cc: Arnaldo de Melo, mingo, Peter Zijlstra, akshay kumar, LKML On Wed, Oct 31, 2012 at 3:12 AM, Namhyung Kim <namhyung@kernel.org> wrote: > On Tue, 30 Oct 2012 08:05:45 -0400, Dhaval Giani wrote: >> On Tue, Oct 30, 2012 at 3:42 AM, Namhyung Kim <namhyung@kernel.org> wrote: >>> Hi Dhaval, >>> >>> On Mon, 29 Oct 2012 12:45:53 -0400, Dhaval Giani wrote: >>>> On Mon, Oct 29, 2012 at 12:01 PM, Dhaval Giani <dhaval.giani@gmail.com> wrote: >>>>> Hi, >>>>> >>>>> As part of a class assignment I have to collect some performance >>>>> statistics. In order to do so I run >>>>> >>>>> perf record -g <the program I have to profile> >>>>> >>>>> And in another window, I start 200 threads of the load generator >>>>> (which is not recorded by perf) >>>>> >>>>> This generates me statistics that I expect to see, and I am happy. As >>>>> this is academia and a class assignment, I need to collect information >>>>> and analyze it across different setups. Which of course meant I script >>>>> this whole thing, which basically is >>>>> >>>>> for i in all possibilities >>>>> do >>>>> perf record -g <the program I have to profile> & >>>>> WAITPID=$! >>>>> for j in NR_THREADS >>>>> do >>>>> <start load generator> & >>>>> KILLPID=$! >>>>> done >>>>> wait $PID >>> >>> You meant $WAITPID, right? >>> >> >> yes. grrr. I changed the name here to WAITPID for it to be clear and >> that was a fail. (I blame the cold) >> >>> >>>>> kill $KILLPID >>> >>> Doesn't it kill the last load generator only? >>> >>> >> >> Well, this was a bug in me typing the pseudo code. the actual script >> does "$KILLPID $!" > > Okay, so I suspect that it might be affected by the autogroup scheduling > feature since you said running load generators in another window - I > guess it's a terminal. How about running them with setsid? > Why would that affect the data collection for the program being profiled? The time spent (since it is a compute intensive program) in various functions shouldn't change, correct? (Unless I am missing something). /me goes and tries it out Hmm. OK, so that doesn't help. Still the same. Thanks! Dhaval ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-10-31 22:15 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-10-29 16:01 [BUG] perf report: different reports when run on terminal as opposed to script Dhaval Giani 2012-10-29 16:45 ` Dhaval Giani 2012-10-30 7:42 ` Namhyung Kim 2012-10-30 12:05 ` Dhaval Giani 2012-10-31 7:12 ` Namhyung Kim 2012-10-31 22:15 ` Dhaval Giani
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.