* Remy Bohmer (l.pinguin@xxxxxxxxx) wrote: > Hello, > > I am looking for some tool/kernel machanism that enables me to track > every schedule change on the CFS scheduler of the RT-kernel for some > period of time. > Thus a tool that gives me an overview after some time which task got > "scheduled in/out" at "which timestamp" and at "which CPU". ( I need > the raw data) > > In a far past (on Montavista kernels) I used LTT for this to log for > some time with only the SCHED_CHANGE filter and text output. But, I > cannot find any LTT(ng) support for any RT-kernel, and support for the > new CFS (like in 2.6.22.1-rt4) is even harder. > > So I was wondering if anybody knows some tool/kernel mechanism which > can do this? > If not, I will build a kernel extension for it myself (new extension > to 'latency_trace' ?) > In that case can anybody with in depth CFS scheduler knowledge please > point me which hooks are safe to use for this? > > I need it to get a detailed insight in my RT-system with its RT and > non-RT applications. > Thus to know when a certain task gets scheduled (and to calculate its > per thread min/max/avg latencies), which task preempts another task, > and to get a complete overview of what the RT system (and scheduler) > is doing during time etc. > Hi Remy, I think Thomas may have worked on a port of recent LTTng to the -RT kernel. If not, I think you needs are quite easy to fulfill with a small amount of work. Basically, you could take a recent copy of LTTng, which comes in a set of logically separated patches: http://ltt.polymtl.ca/lttng/patch-2.6.22-rc4-mm2-lttng-0.9.10.tar.bz2 Follow the Compatibility List to see which other packages you need (ltt-control and lttv) : http://ltt.polymtl.ca/svn/ltt/branches/poly/doc/developer/lttng-lttv-compatibility.html Then, when applying the LTTng patches to the -RT kernel, a few things must be taken care of: 1 - "instrumentation" patches : you won't care about most of the rejects, since you only care about the schedule() calls. 2 - You'll have to see how schedule() is instrumented and port that to the CFS. 3 - Make sure the Linux Kernel Markers (linux/marker.h) _really_ call preempt_disable()/preempt_enable() (is it a underscored function in -rt ?). It is used for correct teardown of probe handlers with synchronize_sched(). Probe sites execute very quickly, do it won't add significant latency to your system. 4 - Ping me for problematic rejects. Mathieu > > Kind Regards, > > Remy Böhmer > -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
