public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@linux.intel.com>
To: Tim Hockin <thockin@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>,
	linux-kernel@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	priyankag@google.com, Aaron Durbin <adurbin@gmail.com>,
	Duncan Laurie <dlaurie@google.com>
Subject: Re: x86/mce merge, integration hickup + crash, design thoughts
Date: Tue, 13 Jan 2009 06:02:24 +0100	[thread overview]
Message-ID: <496C2060.4070205@linux.intel.com> (raw)
In-Reply-To: <b3ece790901121402k4e84f8e7k7993b5fda90456cb@mail.gmail.com>

Tim Hockin wrote:

> 
>>  - it squeezes all MCE errors from the whole system into a small,
>>    32-entry ringbuffer.
> 
> Yes 32 is small, but not really a big problem in practice.  The MCE daemon
> (http://mcedaemon.googlecode.com)

Interesting.

> goes a long way towards making this
> a non-issue.  Every distro should ship mced.

The latest mcelog version (not yet released) also supports a daemon
mode btw. But the limited buffer has been also fixed already
here and replaced with more flexible per CPU buffers.

>>  - it puts all the MCE logging info into an intermediary binary log
>>    record format: 'struct mce' - just for userspace to in essence
>>    printf out those entries with minimal post-processing. The fact that
>>    we squeeze all information into a fixed-size binary record makes it
>>    hard to extend and complicates the code needlessly.
> 
> This is not true, we do EXTENSIVE post-processing of MCEs.  Yes it is hard
> to extend, but that's not the same as saying it is useless.

It's not hard to extend at all (I did it several times)
Adding fields is extremly simple and fully forwards and
backwards compatible. That works because mcelog asks
the kernel about the record size and just ignores any
excess data.

The only thing that cannot be done is removing old fields, but
that is difficult with ASCII parsers too (text parsers tend
to bail out when they can't find some field they expect)

They can be obsoleted fine however (happened with cpu -> extcpu)

> 
>>  - these design aspects are also quite harmful to usability: by
>>    default all MCEs are fatal currently (pre-Nehalem anyway), so
>>    /dev/mcelog will only be used if a user goes out on a limb to
>>    configure it and sets the tolerant flag.
> 
> Not true.  The vast vast vast majority of MCEs are corrected, as per our
> experience, and I suspect we've got more experience with MCEs than just
> about any other consumer.

My employer has a lot of experience with MCEs too...  And it matches your
experience.

-Andi

      reply	other threads:[~2009-01-13  5:02 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-27 15:50 x86/mce merge, integration hickup + crash, design thoughts Ingo Molnar
2008-12-27 22:51 ` Ingo Molnar
2008-12-29 21:41   ` Andi Kleen
2009-01-13 17:45     ` Ingo Molnar
2009-01-13 18:57       ` Tim Hockin
2009-01-14  9:29         ` Andi Kleen
2009-01-14 16:18           ` Tim Hockin
2009-01-14 18:05             ` Andi Kleen
2009-01-14 19:32               ` Tim Hockin
2009-01-15 22:56                 ` Andi Kleen
2009-01-15 23:39                   ` Tim Hockin
2009-01-14  2:02       ` Huang Ying
2008-12-30 21:13   ` Russ Anderson
2008-12-31 13:32     ` Andi Kleen
2008-12-31 18:09       ` Russ Anderson
2008-12-29 21:51 ` Andi Kleen
2008-12-30  6:50   ` Ingo Molnar
2008-12-30  9:13     ` Andi Kleen
2008-12-30 21:29 ` Russ Anderson
2009-01-12 22:02 ` Tim Hockin
2009-01-13  5:02   ` Andi Kleen [this message]

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=496C2060.4070205@linux.intel.com \
    --to=ak@linux.intel.com \
    --cc=adurbin@gmail.com \
    --cc=dlaurie@google.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=priyankag@google.com \
    --cc=tglx@linutronix.de \
    --cc=thockin@gmail.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