* perf sched record with -p option
@ 2018-02-04 17:31 Vuille, Martin (Martin)
2018-02-08 5:07 ` Namhyung Kim
0 siblings, 1 reply; 3+ messages in thread
From: Vuille, Martin (Martin) @ 2018-02-04 17:31 UTC (permalink / raw)
To: linux-perf-users
The data files collected by 'perf sched record' are very large and our embedded
system target has limited storage, so I thought of using the '-p PID' option on
'perf sched record' to focus only on a single PID and its threads/children and
thus reduce the amount of data.
However, when I review the results with 'perf sched latency', the results from
data collected with '-p PID' are significantly different (e.g., ten-times longer
latencies) that those from data collected without the '-p PID' option. Workloads
are the same.
Is there some reason why using '-p PID' option on 'perf sched record' wouldn't
make sense?
MV
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: perf sched record with -p option
2018-02-04 17:31 perf sched record with -p option Vuille, Martin (Martin)
@ 2018-02-08 5:07 ` Namhyung Kim
2018-02-13 13:11 ` Vuille, Martin (Martin)
0 siblings, 1 reply; 3+ messages in thread
From: Namhyung Kim @ 2018-02-08 5:07 UTC (permalink / raw)
To: Vuille, Martin (Martin); +Cc: linux-perf-users, kernel-team
Hello,
On Sun, Feb 04, 2018 at 05:31:07PM +0000, Vuille, Martin (Martin) wrote:
> The data files collected by 'perf sched record' are very large and our embedded
> system target has limited storage, so I thought of using the '-p PID' option on
> 'perf sched record' to focus only on a single PID and its threads/children and
> thus reduce the amount of data.
>
> However, when I review the results with 'perf sched latency', the results from
> data collected with '-p PID' are significantly different (e.g., ten-times longer
> latencies) that those from data collected without the '-p PID' option. Workloads
> are the same.
>
> Is there some reason why using '-p PID' option on 'perf sched record' wouldn't
> make sense?
I think it's because perf missed sched-in and wakeup events for the PID
since they are from different tasks.
Thanks,
Namhyung
^ permalink raw reply [flat|nested] 3+ messages in thread
* RE: perf sched record with -p option
2018-02-08 5:07 ` Namhyung Kim
@ 2018-02-13 13:11 ` Vuille, Martin (Martin)
0 siblings, 0 replies; 3+ messages in thread
From: Vuille, Martin (Martin) @ 2018-02-13 13:11 UTC (permalink / raw)
To: Namhyung Kim; +Cc: linux-perf-users, kernel-team
> On Sun, Feb 04, 2018 at 05:31:07PM +0000, Vuille, Martin (Martin) wrote:
> > The data files collected by 'perf sched record' are very large and our
> > embedded system target has limited storage, so I thought of using the
> > '-p PID' option on 'perf sched record' to focus only on a single PID
> > and its threads/children and thus reduce the amount of data.
> >
> > However, when I review the results with 'perf sched latency', the
> > results from data collected with '-p PID' are significantly different
> > (e.g., ten-times longer
> > latencies) that those from data collected without the '-p PID' option.
> > Workloads are the same.
> >
> > Is there some reason why using '-p PID' option on 'perf sched record'
> > wouldn't make sense?
>
> I think it's because perf missed sched-in and wakeup events for the PID since
> they are from different tasks.
Thanks.
I am checking the collected events and comparing with and without -p option.
I am collecting data for 60 seconds (passing command 'sleep 60' to perf.)
I have found something very, very odd. When I include the -p option, for the
first 50 or so seconds of the capture, there are only sched_wakeup events
recorded. After that, I start seeing all the events, sched_wakeup, sched_switch,
etc.
Any thoughts?
Regards,
MV
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2018-02-13 13:11 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-02-04 17:31 perf sched record with -p option Vuille, Martin (Martin)
2018-02-08 5:07 ` Namhyung Kim
2018-02-13 13:11 ` Vuille, Martin (Martin)
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.