Messages in this thread | | | Date | Wed, 02 Dec 2009 13:07:18 -0500 | From | Masami Hiramatsu <> | Subject | Re: [PATCH v2] mm: Introduce coredump parameter structure |
| |
Ingo Molnar wrote: > * Masami Hiramatsu<mhiramat@redhat.com> wrote: > >> Andrew Morton wrote: >>> On Sat, 28 Nov 2009 23:41:19 -0500 >>> Masami Hiramatsu<mhiramat@redhat.com> wrote: >>> >>>> Introduce coredump parameter data structure (struct coredump_params) >>>> for simplifying binfmt->core_dump() arguments. >>>> >>>> Changes in v2: >>>> - Don't remove DUMP_WRITE() macro. >>> >>> What is the reason for this change? >>> >>> Please always include both the "what" and the "why" in changelog text. >> >> I see. > > I think Andrew wanted to see a longer explanation about precisely what > we need for these tracepoints and what the various specific usecases are > to utilize it.
Ah, OK.
> > I.e. a basic cost/benefit analysis is needed. By looking at the patch we > can see the cost - but you have to counter-balance that with enough > stuff in the 'benefits' column of the equation.
Hmm, actually, this tracepoint requirement comes from the viewpoint of administrators (not developers). Since now we have introduced many coredump configurations (e.g. dumpable, coredump_filter, core_pattern, etc) and some of them can be modified by users, we assume it is hard to know what was actually dumped (or not dumped) after some problem happened on the system. For example, a process didn't generated core, coredump doesn't have some sections, etc. In those cases, the coredump tracepoint can help us to know why the core file is so big or small, or not generated, by recording all configurations for all processes on the system. That will reduce system-administration cost.
Thank you,
-- Masami Hiramatsu
Software Engineer Hitachi Computer Products (America), Inc. Software Solutions Division
e-mail: mhiramat@redhat.com
| |