Hi Dmitry, On Apr 11, 2012, at 11:02 AM, Dmitry Antipov wrote:
> On 04/09/2012 09:24 PM, Pantelis Antoniou wrote: > >> Here's a updated patch for builtin-sched.c that should fix your issues. >> >> Now when you issue list a field will show the amount of nsecs the >> task was burning cycles. >> >> It should also fix the crash you've encountered. > > 1) IIUC, 'perf sched spr-replay -l' should lists the tasks only, but it looks > like it tries to execute something just after displaying the list. While > this > command is running, I can see a lot of perf processes, like: > > root 2846 28.0 1.8 30552 19328 pts/0 S+ 07:51 0:01 perf sched > spr-replay -l > root 2847 36.6 1.4 30552 14572 pts/0 R+ 07:51 0:01 perf sched > spr-replay -l > root 2848 11.6 1.4 30552 14580 pts/0 S+ 07:51 0:00 perf sched > spr-replay -l > root 2849 36.3 1.4 30552 14548 pts/0 R+ 07:51 0:01 perf sched > spr-replay -l > root 2850 13.0 1.4 30552 14576 pts/0 S+ 07:51 0:00 perf sched > spr-replay -l > root 2851 7.3 1.4 30552 14584 pts/0 S+ 07:51 0:00 perf sched > spr-replay -l > root 2852 0.0 1.4 30552 14584 pts/0 S+ 07:51 0:00 perf sched > spr-replay -l > root 2853 5.0 1.4 30552 14588 pts/0 S+ 07:51 0:00 perf sched > spr-replay -l > root 2854 0.0 1.4 30552 14576 pts/0 S+ 07:51 0:00 perf sched > spr-replay -l > root 2855 0.0 1.4 30552 14576 pts/0 S+ 07:51 0:00 perf sched > spr-replay -l > root 2856 0.0 1.4 30552 14576 pts/0 S+ 07:51 0:00 perf sched > spr-replay -l > root 2857 0.0 1.4 30552 14576 pts/0 S+ 07:51 0:00 perf sched > spr-replay -l > root 2858 37.3 1.4 30552 14548 pts/0 R+ 07:51 0:01 perf sched > spr-replay -l > root 2859 37.3 1.4 30552 14548 pts/0 R+ 07:51 0:01 perf sched > spr-replay -l > root 2860 35.3 1.4 30552 14548 pts/0 R+ 07:51 0:01 perf sched > spr-replay -l > root 2861 37.3 1.4 30552 14548 pts/0 R+ 07:51 0:01 perf sched > spr-replay -l > > And: > > perf: builtin-sched.c:2621: execute_wait_id: Assertion `ret == 0 || ret == > 11' failed. > > from one of them. > If you don't want to run anything, use the -n switch (dry-run). Arguably -l could assume -n, but passing -n works for now. I'm not that happy about the crash. I'll try to check it out. > 2) When I'm trying to generate SPR from an interesting process with 'perf > sched spr-replay -s 2580 -g', > I got: > > [testbrowser/2580] > burn 36007422086 > exit 0 > end > > I suppose this is wrong because it means that testbrowser/2580 newer yields > the CPU until exit. > OK, a bit of an expanding on that is required. By default, spr-replay will not preserve recorded timing. To preserve timing you can supply the -p switch which will cause the timing of the recorded process to be observed. Let's take for example a process that is burning CPU and doesn't yield explicitly. At regular intervals it would be switched out of the CPU so that another process would execute, but it's state would still be running. That means that in an ideal system with infinite CPUs it would be possible to execute. That is what we want to record, since the actual intention of the process would be to continue running but due to limited CPU resources it is interrupted. Try running this with the -p switch, or include more processes with the -s switch. Also, since you are not including any other processes that might signal this one, you effectively remove them from being recorded, so if testbrowser was waiting for a signal from another process that is not part of the schedule, the wait will be removed. > Could you try to look at my perf.data and replay testbrowser/2580? Gzipped > copy is here: > http://78.153.153.8/tmp/perf.data.gz > > Thanks, > Dmitry OK, will check. Regards -- Pantelis _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
