lkml.org 
[lkml]   [2009]   [Jan]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: x86/mce merge, integration hickup + crash, design thoughts
Tim Hockin wrote:
> Yeah, no offense, but that's horrible :)

I'm not sure it's worse than the XML like format proposals that seem to
get thrown around. That is I am the only one who mentioned the
X word yet, but the structured ASCII records that have been hinted
at would be exactly like that.

>
> Ideally, I'd rather see a more generic conduit for all sorts of
> events. Polled and exception MCEs. Thermal interrupts. MCE
> threshold interrupts.

Actually I think now MCE threshold interrupts should have never been
separate events. That was a design mistake in the AMD implementation
(together with all the sysfs complications)

An MCE threshold interrupt is just a slightly different internal
notification mechanism and it should only trigger the events it reads
from the MCE banks. Nothing more.
My upcoming CMCI code works exactly this way.

> PCI-express errors.

Yes we need some mechanism for those. Fortunately that's easier
because it doesn't need to handle NMIs.

> SATA
> disk timeouts.

Now that's a different issue. Generalized driver error reporting for everyone.

There was a lot of discussion some years ago from a IBM proposal to do
in general structured error reporting. But that was quite unpopular
and no-one really liked it.

What came out of it was the dev_printk() stuff that allows
to match error messages to devices. So you already have some
baby steps in this direction.

I suspect doing this fully generalized would be quite difficult
because there would be so many people you have to convince.



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

Well the kernel will always have limited buffers, so the someone
needs to listen problem will be always there.

There are not __that__ many I think.

Also whatever code handles this has to have special code for
all of these anyways, so having a variety of interfaces for them
doesn't seem like the end of the world to me.

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

Sure sounds nice. But frankly I don't see it happening. It would
be just too radical a change of too much code.

-Andi



\
 
 \ /
  Last update: 2009-01-16 00:07    [W:0.075 / U:1.284 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site