Re: [RFC PATCH 28/30 v3] Generic command line storage

[Steven Rostedt]

On Tue, 15 Jan 2008, Mathieu Desnoyers wrote:

> * Steven Rostedt (rostedt@xxxxxxxxxxx) wrote:
> > Saving the comm of tasks for each trace is very expensive.
> > This patch includes in the context switch hook, a way to
> > store the last 100 command lines of tasks. This table is
> > examined when a trace is to be printed.
> >
>
> Instead of saving the comm at context switch, could we save them when a
> process exits ? (actually, if we want to do this right, we would also
> have to trace the changes of "comm" upon exec(), so we deal correctly
> with processes that do multiple execs).
>
> This way, we would not duplicate the comm of processes still active in
> the system, and would trigger on a much lower event-rate trace point.
>
> And the idea would be to save only the comm of processes present in your
> summary (top X processes); why do you save the last 100 ? (if the system
> has more than 100 active tasks, this code will always be executed, which
> seems bad)

100 was just an arbitrary number that seems to be fine in my current
tests. But yes, a function trace over a thousand tasks will clean them
out. But the recording is only done when a trace is active.

>
> Also, if we do as I propose, we would have to keep process exit/exec
> tracing active until the summary is cleared, even though the rest of
> "high event rate" tracing could be stopped sooner.

One thing I planned on doing was at a low path point (hit max latency to
record, etc) we could copy the array into the trace buffer, so the info
stays with the trace.

Going with your approach (marker at exit), I could flush the traces that
were saved, as well as the comms of the current tasks that are still
running. The thing is, this all starts to get a bit intrusive into the
rest of the kernel.  What is suppose to be a compact latency tracer,
starts to become larger, problematic, entity. Now changes in exit could
require updates to the tracer. Which is something I want to avoid.

-- Steve

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/