Messages in this thread | | | Date | Tue, 18 May 2010 21:34:37 +0200 | From | Ingo Molnar <> | Subject | Re: Hardware Error Kernel Mini-Summit |
| |
* Borislav Petkov <bp@amd64.org> wrote:
> Well, we have a trace_mce_record tracepoint in the > mcheck code which calls all the necessary callbacks when > an mcheck occurs. For the time being, the idea is to use > the mce.c ring buffer for early mchecks and copy them to > the regular ftrace per-cpu buffer after the last has > been initialized. Later, we could switch to a another > early bootmem buffer if there's need to.
The end result would be even simpler by one more step: with persistent events we just use them and dont need the mce.c ringbuffer at all. (getting rid of that complication is one of the code cleanliness benefits i see in this move as a x86 maintainer - beyond the obvious generalization and unification benefits.)
> Also, we want to have a userspace daemon that reads out > the mces from the trace buffer and does further > processing like thresholding etc in userspace. > > Concerning critical errors, there we bypass the perf > subsystem and execute the smallest amount of code > possible while trying to shutdown gracefully if the > error type allows that.
Yeah. Each perf_event can have arbitrary callbacks with add-on (or critical) functionality. We would activate the event(s) during bootup and it would do its thing from that point on: critical functionality gets a direct path via the callback, and every other event that survives goes via the regular perf output channels, to one (or more) consumers/subscribers of these events.
Ingo
| |