All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: davidm@hpl.hp.com
Cc: davidm@napali.hpl.hp.com, iod00d@hp.com,
	ishii.hironobu@jp.fujitsu.com, linux-kernel@vger.kernel.org,
	linux-ia64@vger.kernel.org
Subject: Re: [RFC/PATCH, 1/4] readX_check() performance evaluation
Date: Wed, 28 Jan 2004 18:52:46 +0000	[thread overview]
Message-ID: <20040128195246.47a84498.ak@suse.de> (raw)
In-Reply-To: <16408.30.896895.980121@napali.hpl.hp.com>

On Wed, 28 Jan 2004 10:31:58 -0800
David Mosberger <davidm@napali.hpl.hp.com> wrote:

> >>>>> On Wed, 28 Jan 2004 18:41:37 +0100, Andi Kleen <ak@suse.de> said:
> 
>   Andi> Also in my experience from AMD64 which originally was a bit
>   Andi> aggressive on enabling MCEs: enabling MCEs increases your
>   Andi> kernel support load a lot.
> 
>   Andi> Many people have slightly buggy systems which still happen to
>   Andi> work mostly.  If you report every problem you as kernel
>   Andi> maintainer will be flooded with reports about things you can
>   Andi> nothing to do about.
> 
> I find this comment interesting.  Can you elaborate what you mean by
> "slightly buggy systems"?

e.g. one bit ECC errors in memory are quite common.  And with ECC memory 
they are not really fatal. Similar with drivers. A lot of drivers do 
bus aborts and other things regularly, but there is not necessarily 
data corruption.

-Andi

WARNING: multiple messages have this Message-ID (diff)
From: Andi Kleen <ak@suse.de>
To: davidm@hpl.hp.com
Cc: davidm@napali.hpl.hp.com, iod00d@hp.com,
	ishii.hironobu@jp.fujitsu.com, linux-kernel@vger.kernel.org,
	linux-ia64@vger.kernel.org
Subject: Re: [RFC/PATCH, 1/4] readX_check() performance evaluation
Date: Wed, 28 Jan 2004 19:52:46 +0100	[thread overview]
Message-ID: <20040128195246.47a84498.ak@suse.de> (raw)
In-Reply-To: <16408.30.896895.980121@napali.hpl.hp.com>

On Wed, 28 Jan 2004 10:31:58 -0800
David Mosberger <davidm@napali.hpl.hp.com> wrote:

> >>>>> On Wed, 28 Jan 2004 18:41:37 +0100, Andi Kleen <ak@suse.de> said:
> 
>   Andi> Also in my experience from AMD64 which originally was a bit
>   Andi> aggressive on enabling MCEs: enabling MCEs increases your
>   Andi> kernel support load a lot.
> 
>   Andi> Many people have slightly buggy systems which still happen to
>   Andi> work mostly.  If you report every problem you as kernel
>   Andi> maintainer will be flooded with reports about things you can
>   Andi> nothing to do about.
> 
> I find this comment interesting.  Can you elaborate what you mean by
> "slightly buggy systems"?

e.g. one bit ECC errors in memory are quite common.  And with ECC memory 
they are not really fatal. Similar with drivers. A lot of drivers do 
bus aborts and other things regularly, but there is not necessarily 
data corruption.

-Andi

  reply	other threads:[~2004-01-28 18:52 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-28  1:54 [RFC/PATCH, 1/4] readX_check() performance evaluation Hironobu Ishii
2004-01-28  1:54 ` Hironobu Ishii
2004-01-28 17:20 ` Grant Grundler
2004-01-28 17:20   ` Grant Grundler
2004-01-28 17:41   ` Andi Kleen
2004-01-28 17:41     ` Andi Kleen
2004-01-28 18:31     ` David Mosberger
2004-01-28 18:31       ` David Mosberger
2004-01-28 18:52       ` Andi Kleen [this message]
2004-01-28 18:52         ` Andi Kleen
2004-01-28 19:24         ` David Mosberger
2004-01-28 19:24           ` David Mosberger
2004-01-28 19:39           ` Andi Kleen
2004-01-28 19:39             ` Andi Kleen
2004-01-28 19:48             ` David Mosberger
2004-01-28 19:48               ` David Mosberger
2004-01-28 20:01               ` Andi Kleen
2004-01-28 20:01                 ` Andi Kleen
2004-01-28 23:35                 ` David Mosberger
2004-01-28 23:35                   ` David Mosberger
2004-02-16 10:19             ` Pavel Machek
2004-02-16 10:19               ` Pavel Machek
2004-01-28 19:09     ` Grant Grundler
2004-01-28 19:09       ` Grant Grundler
2004-01-28 19:17       ` Andi Kleen
2004-01-28 19:17         ` Andi Kleen
2004-01-28 21:14         ` Grant Grundler
2004-01-28 21:14           ` Grant Grundler
2004-01-28 21:39           ` Andi Kleen
2004-01-28 21:39             ` Andi Kleen
2004-01-29  8:23 ` Matthias Fouquet-Lapar
2004-01-29  8:23   ` Matthias Fouquet-Lapar
2004-01-29 19:28   ` David Mosberger
2004-01-29 19:28     ` David Mosberger
2004-01-29 20:16 ` Matthias Fouquet-Lapar
2004-01-29 20:16   ` Matthias Fouquet-Lapar
2004-01-29 21:09   ` David Mosberger
2004-01-29 21:09     ` David Mosberger
2004-01-29 22:20 ` Matthias Fouquet-Lapar
2004-01-29 22:20   ` Matthias Fouquet-Lapar

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=20040128195246.47a84498.ak@suse.de \
    --to=ak@suse.de \
    --cc=davidm@hpl.hp.com \
    --cc=davidm@napali.hpl.hp.com \
    --cc=iod00d@hp.com \
    --cc=ishii.hironobu@jp.fujitsu.com \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.