Messages in this thread | | | Date | Thu, 15 Jan 2009 23:56:43 +0100 | From | Andi Kleen <> | Subject | Re: 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
| |