Message-ID: <4BCF0C39.1080907@redhat.com>
Date:	Wed, 21 Apr 2010 10:31:21 -0400
From:	Masami Hiramatsu <mhiramat@...hat.com>
To:	Roland McGrath <roland@...hat.com>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	lkml <linux-kernel@...r.kernel.org>,
	systemtap <systemtap@...rces.redhat.com>,
	DLE <dle-develop@...ts.sourceforge.net>,
	Oleg Nesterov <oleg@...hat.com>,
	Jason Baron <jbaron@...hat.com>, Ingo Molnar <mingo@...e.hu>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
Subject: Re: [PATCH -mm v6] tracepoint: Add signal coredump tracepoint

Hi Roland,

Roland McGrath wrote:
>> 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.

OK, please read the previous discussion and tell me what you think about...
https://patchwork.kernel.org/patch/64345/
---
> > What do you think this tracepoint's use case?
> 
> Frankly to say, our first attempt was tracing mm->flags because
> it can be changed by users without asking, and they sometimes
> ask why core is not perfect or why core file is so big.
> 
> Perhaps, covering all of those failure cases and succeed cases,
> gives better information for them. In that case, we might better
> tweak execution(goto) path to leave some error code on retval.

This is enough acceptable to me.
---

> 
>> 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.

No, that's not our interests. We are just interested in recording
coredump parameters when the coredump is done. After dumping core
(or failing to dump), we'd like to check what was wrong (wrong filter setting?),
or correctly dumped (and removed after).

> 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.

Hmm, currently, we don't mention that.

> 
>> -	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.

hm, ok. that's nice to fix.

Thank you,

> 
> 
> Thanks,
> Roland

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

Powered by blists - more mailing lists