Re: [PATCH 09/11] sched: export task_prio to GPL modules

Mathieu Desnoyers
2011-12-01T23:47:19Z

* Greg KH (greg@kroah.com) wrote:
> On Fri, Dec 02, 2011 at 12:06:37AM +0100, Peter Zijlstra wrote:
> > On Thu, 2011-12-01 at 17:15 -0500, Mathieu Desnoyers wrote:
> > >
> > > If you don't want to trace sched_switch, but just conveniently prepend
> > > this information to all your events
> >
> > Oh so you want to debug a scheduler issue but don't want to use the
> > scheduler tracepoint, I guess that makes perfect sense for clueless
> > people.
>
> Matheiu, can't lttng use the scheduler tracepoint for this information?

LTTng allows user to choose between both methods, each one being suited
to a particular use of the tracer:

A) Extraction through the scheduler tracepoint:

LTTng viewers have a full-fledged current state reconstruction of the
traced OS (for any point in time during the trace) performed as one
of the bottom layers of our trace analysis tools. This makes sense
for use-cases where the data needs to be transported, and/or stored,
and where the amount of data throughput needs to be minimized. We use
this technique a lot, of course. This state-tracking requires
CPU/memory resource usage by the viewer.

B) Extraction through "optional" event context information:

We have, in development, a new "enhanced top" called lttngtop that
uses tracing information, directly read from mmap'd buffers, to
provide second-by-second profile information of the system. It is
not as sensitive to data compactness as the transport/disk storage
use-case, mainly because no data copy is ever required -- the buffers
simply get overwritten after lttngtop has finished aggregating the
information. This has less performance overhead that the big hammer
"top" that periodically reads all files in /proc, and can provide
much more detailed profiles.

This use-case favors sending additional data from kernel to
user-space rather than recomputing the OS state within lttngtop, due
to the very low overhead of direct mmap data transport, over
recomputing state needlessly.

We could very well "cheat" and use a scheduler tracepoint to keep a
duplicate of the current priority value for each CPU within the tracer
kernel module. Let me know if you want me to do this.

Also, as a matter of fact, the "prio" information exported from the
sched_switch event in mainline trace events does not match the prio
shown in /proc stat files. The "MAX_RT_PRIO" offset is missing.

Thanks,

Mathieu

--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.