[RFC] Scheduler recorder and playback

[Pantelis Antoniou]

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