On Thu, Jun 25, 2015 at 12:48 AM, Peter Zijlstra <[email protected]> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
