Messages in this thread | | | Date | Thu, 25 Jun 2015 10:17:58 -0700 | Subject | Re: [PATCH] sched: split sched_switch trace event into two | From | Cong Wang <> |
| |
On Thu, Jun 25, 2015 at 12:48 AM, Peter Zijlstra <peterz@infradead.org> wrote: > On Wed, Jun 24, 2015 at 04:19:33PM -0700, Cong Wang wrote: >> Currently we only have one sched_switch trace event >> for task switching, which is generated very early during >> task switch. When we try to monitor per-container events, >> this is not what we expect. > > Adjust your expectations? > >> For example, we have a process A which is in the cgroup >> we monitor, and process B which isn't, when kernel switches >> from B to A, the sched_switch event is not recorded for this >> cgroup since it belongs to B (current process is still B >> util we finish the switch), but we require this event to >> signal that process A in this cgroup gets scheduled. This is >> crucial for calculating schedule latency. > > I don't get it. This is global data in the root pid-space. > > The switch data includes both the previous and the next task. Just look > up their corresponding cgroups and be done with it.
This is exactly how I _workaround_ this issue for now. :)
But it is not that easy, because we need to track new processes and dying processes to maintain the pid list.
> > If you cannot get what you want from it, you're doing it wrong.
The problem is why user-space has to do that (as mentioned above) just to track their cgroup since we already have perf_event cgroup.
All what I want is tracking several sched events within a given perf_event cgroup and calculating the sched latency (like how `perf sched` does), and sched_switch is an exception since it is related with two processes which can be in two different perf_event cgroups, and since it is generated early during task switch, all sched_switch events belong to 'prev' task, we lose the track of the sched_switch for 'next' task.
Fixing it in kernel is easier than workaround in user-space, this is why I come up with this patch.
Thanks.
| |