lkml.org 
[lkml]   [2009]   [Jan]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: x86/mce merge, integration hickup + crash, design thoughts
From
On Wed, Jan 14, 2009 at 10:05 AM, Andi Kleen <ak@linux.intel.com> wrote:
>
>>
>> From my point of view: a single, consistent, easy logging interface
>> for the kernel to send *structured data* about hardware/system events
>> and errors up to userspace.
>
> Which kinds of events were you thinking of?
>
> So far we managed by cramming some other CPU events like thermal
> trip into "pseudo banks" in struct mce. Admittedly it's not the
> most pretty solution in the world, but it worked.

Yeah, no offense, but that's horrible :)

Ideally, I'd rather see a more generic conduit for all sorts of
events. Polled and exception MCEs. Thermal interrupts. MCE
threshold interrupts. EDAC polled errors. PCI-express errors. SATA
disk timeouts.

Now I know there are different conduits for some events - netlink
tells me about netif link up/down events I think. I would settle for
a small number of interfaces. What I don't want is what we have today
- EVERYTHING has a different interface. Some are poll()-able. Some
have to be actively polled. Some have to have a daemon listening or
else messages are dropped. Some have to parse logs. Puke.

Put it this way: Given a thousand machines, I want to gather,
collate, and correlate all these events. I want to be able to produce
a "life story" of sorts for a machine and for a data center. Once I
can do that, I can start to make predictive diagnoses more accurately,
and I can know how much these things actually COST us.

Tim


\
 
 \ /
  Last update: 2009-01-14 20:35    [W:0.095 / U:0.248 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site