This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [PATCH -mm v6] tracepoint: Add signal coredump tracepoint
- From: Roland McGrath <roland at redhat dot com>
- To: Masami Hiramatsu <mhiramat at redhat dot com>
- Cc: Andrew Morton<akpm at linux-foundation dot org>, lkml<linux-kernel at vger dot kernel dot org>, systemtap<systemtap at sources dot redhat dot com>, DLE<dle-develop at lists dot sourceforge dot net>, Oleg Nesterov <oleg at redhat dot com>, Jason Baron <jbaron at redhat dot com>, Ingo Molnar <mingo at elte dot hu>, KOSAKI Motohiro <kosaki dot motohiro at jp dot fujitsu dot com>
- Date: Tue, 20 Apr 2010 17:18:56 -0700 (PDT)
- Subject: Re: [PATCH -mm v6] tracepoint: Add signal coredump tracepoint
- References: <20100412164830.514.85103.stgit@localhost6.localdomain6>
> Add signal coredump tracepoint which shows signal number,
> mm->flags, core file size limitation, the result of
> coredump, and core file name.
The "retval" encoding seems a bit arcane. I wonder if it might be better
to just have separate tracepoints for successful and failed dump attempts.
Note that whether or not the dump succeeded is already available in
(task->signal->group_exit_code & 0x80) as seen at exit or death tracing
events.
> This tracepoint requirement comes mainly from the viewpoint of
> administrators. [...]
The purposes you mention seem to be served well enough by this tracepoint.
But I recall having the impression that one of the original motivating
interests for tracing core-dump details was to understand when a giant core
dump was responsible for huge amounts of i/o and/or memory thrashing.
(Once you notice that happening, you might adjust coredump_filter settings
to reduce the problem.) Your new tracepoint doesn't help directly with
tracking those sorts of issues, because it only happens after all the work
is done. If you are monitoring trace_signal_deliver, then you can filter
those for SIG_DFL cases of sig_kernel_coredump() signals and recognize that
as the beginning of the coredump. Still, it might be preferable to have
explicit start-core-dump and end-core-dump tracepoints.
Furthermore, I can see potential use for tracepoints before and after
coredump_wait(), which synchronizes other threads before actually starting
to calculate and write the dump. The window after coredump_wait() and
before the post-dump tracepoint is where the actual work of writing the
core file takes place, in case you want to monitor i/o load between those
marks or suchlike.
> - char corename[CORENAME_MAX_SIZE + 1];
> + char corename[CORENAME_MAX_SIZE + 1] = "";
This initialization of a stack array means the same as:
memset(corename, '\0', sizeof corename);
So the compiler generates that because those are the semantics.
All you need is:
corename[0] = '\0';
since this is a string.
Thanks,
Roland