public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: linux-kernel@vger.kernel.org, ying.huang@intel.com, bp@alien8.de,
	tglx@linutronix.de, akpm@linux-foundation.org,
	mchehab@redhat.com, "Frédéric Weisbecker" <fweisbec@gmail.com>,
	"Steven Rostedt" <rostedt@goodmis.org>,
	"Arnaldo Carvalho de Melo" <acme@redhat.com>,
	"Peter Zijlstra" <a.p.zijlstra@chello.nl>,
	"Arjan van de Ven" <arjan@infradead.org>
Subject: Re: [RFC/Requirements/Design] h/w error reporting
Date: Wed, 10 Nov 2010 11:14:50 +0100	[thread overview]
Message-ID: <20101110101450.GA18481@elte.hu> (raw)
In-Reply-To: <4cd9edd7543527b78@agluck-desktop.sc.intel.com>


* Luck, Tony <tony.luck@intel.com> wrote:

> Taking a cue from the tracing session from the previous day (where the "perf" vs. 
> "ftrace" vs. "lttng" war was ended by proposing a new tracing methodology that 
> would overcome the shortcomings of both of the merged subsystems while also 
> addressing the requirements of the lttng users) [...]

Well, the direction is that we are unifying ftrace and perf events and we are 
actively phasing out individual ftrace plugins as matching events become available 
(we already removed a few).

Most new tools use the perf syscall and tool writers have expressed the very 
understandable desire that all events (and their reporting facility) be enumerated 
and accessible via a unified API/ABI.

While it often seems easier for subsystems to just do their own ad-hoc 
logging/reporting in the short run (every subsystem tends to think it has its own 
very specific requirements for logging - while users/tool-authors can only shake 
their head in disbelief when looking at the myriads of incompatible and inconsistent 
facilities). The tooling requirement for unification is strong here and can not be 
ignored.

> [...] we explored whether the solution would be to define a new "system health" 
> subsystem that could be used by any part of the kernel to report hardware issues 
> in a coherent way so that end users would have a single place to look for all 
> error information.

Note that Boris has been working on extending perf events into this area as well, 
see this recent submission of patches on lkml:

  [PATCH 20/20] ras: Add RAS daemon

One thing is clear: any 'health subsystem' should not do its own flavor of error 
reporting - instead we want to unify various forms of event logging into a common 
facility.

RAS/EDAC could do its own hardware-specific settings via a separate subsystem - 
although even many of those can be expressed via their respective events. (and we 
are open on the perf events side to give callbacks/facilities for such use)

The synergies of unified event reporting are very strong.

Thanks,

	Ingo

  reply	other threads:[~2010-11-10 10:15 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-10  0:56 [RFC/Requirements/Design] h/w error reporting Luck, Tony
2010-11-10 10:14 ` Ingo Molnar [this message]
2010-11-10 14:40   ` Steven Rostedt
2010-11-10 14:43     ` Peter Zijlstra
2010-11-10 15:09       ` Steven Rostedt
2010-11-10 15:28         ` Mathieu Desnoyers
2010-11-10 15:30         ` Peter Zijlstra
2010-11-10 15:53           ` Steven Rostedt
2010-11-10 16:52           ` Steven Rostedt
2010-11-10 17:05             ` Borislav Petkov
2010-11-10 17:41               ` Ingo Molnar
2010-11-10 17:50                 ` Luck, Tony
2010-11-10 18:09                 ` Steven Rostedt
2010-11-10 18:52                   ` Ingo Molnar
2010-11-10 17:25             ` Frederic Weisbecker
2010-11-10 17:48           ` Ingo Molnar
2010-11-10 18:05             ` Steven Rostedt
2010-11-10 18:23               ` Luck, Tony
2010-11-10 18:31                 ` Peter Zijlstra
2010-11-10 18:49                   ` Ingo Molnar
2010-11-10 18:24               ` Peter Zijlstra
2010-11-10 18:41                 ` Ingo Molnar
2010-11-10 19:00                   ` Steven Rostedt
2010-11-10 19:11                     ` Ingo Molnar
2010-11-10 19:11                     ` Frederic Weisbecker
2010-11-10 19:30                       ` Ingo Molnar
2010-11-10 19:48                         ` Steven Rostedt
2010-11-10 20:23                       ` Tracing Requirements (was: [RFC/Requirements/Design] h/w error reporting) Mathieu Desnoyers
2010-11-10 20:54                         ` Luck, Tony
2010-11-10 21:06                           ` Steven Rostedt
2010-11-10 21:34                             ` Steven Rostedt
2010-11-10 22:51                           ` Mathieu Desnoyers
2010-11-10 23:12                             ` Thomas Gleixner
2010-11-10 23:20                               ` Steven Rostedt
2010-11-10 23:45                                 ` Thomas Gleixner
2010-11-11 18:25                                 ` Ted Ts'o
2010-11-10 23:28                               ` Mathieu Desnoyers
2010-11-10 23:58                                 ` Thomas Gleixner
2010-11-11  9:17                                   ` Ingo Molnar
2010-11-11 13:37                                     ` Mathieu Desnoyers
2010-11-10 21:30                         ` Frederic Weisbecker
2010-11-10 21:54                           ` Steven Rostedt
2010-11-10 22:19                             ` Frederic Weisbecker
2010-11-10 22:49                             ` Frederic Weisbecker
2010-11-11  0:11                           ` Mathieu Desnoyers
2010-11-11 16:10                             ` Steven Rostedt
2010-11-11 16:34                               ` Mathieu Desnoyers
2010-11-10 19:16                 ` [RFC/Requirements/Design] h/w error reporting Steven Rostedt
2010-11-10 19:38                 ` Steven Rostedt
2010-11-10 18:27               ` Ingo Molnar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20101110101450.GA18481@elte.hu \
    --to=mingo@elte.hu \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=arjan@infradead.org \
    --cc=bp@alien8.de \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mchehab@redhat.com \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=ying.huang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox