public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: Matthias Fouquet-Lapar <mfl@kernel.paris.sgi.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [RFC] Better MCA recovery on IPF
Date: Sat, 01 Nov 2003 06:39:52 +0000	[thread overview]
Message-ID: <marc-linux-ia64-106766923419071@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-106724227826901@msgid-missing>

Hi,

> Of course, I agree with a common frame set.
> In the case of platform premising IPF, I think it is
> better to regard the Intel's Chipset as the de facto
> standard.

I think there should be an abstraction layer hiding the underlying
HW implementation. I think handling for example a memory error 
by killing the affected user application, should work on any chipset
and/or CPU architecture (if technically possible). We should not
restrict ourselves to specific platforms, I think the general trend
is that the error rate will go up because :

    - faster off-chip frequencies
	- lower supply voltages decreasing signal/noise ratio
	- higher suspectibility to cosmis rays causing SEU (Single Event Upsets)
	  due to smaller process. There are for example estimations that SEUs
	  will increase by a factor of 100 when going from a .13um process to .9um

The only alternatives to burrying a system under 50 feet of solid rock to avoid
cosmic rays and improvements in HW design (chipkill will help) is to improve
error handling and recovery.

Today we have for example the ability that an application can deal with
an unexpected event, such as a div by 0. In my eyes it would be possible
that an application also could make provisions to handle memory (or cache
errors) up to a certain extend, as long as the offending VA is known.

In other words, I would prefer the option for applications writers to 
have the option to recover within the application if is possible instead
of having the application killed (or even the OS in the current state)

Thanks

Matthias Fouquet-Lapar  Core Platform Software    mfl@sgi.com  VNET 521-8213
Principal Engineer      Silicon Graphics          Home Office (+33) 1 3047 4127


  parent reply	other threads:[~2003-11-01  6:39 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-27  8:07 [RFC] Better MCA recovery on IPF Hidetoshi Seto
2003-10-27 16:58 ` Matthias Fouquet-Lapar
2003-10-31  5:09 ` Hidetoshi Seto
2003-10-31 17:14 ` Grant Grundler
2003-11-01  6:39 ` Matthias Fouquet-Lapar [this message]
2003-11-01  8:38 ` Keith Owens
2003-11-02 13:33 ` Matthias Fouquet-Lapar
2003-11-03 17:09 ` Russ Anderson
2003-11-03 17:37 ` Matthias Fouquet-Lapar
2003-11-03 17:51 ` Alberto Munoz
2003-11-03 17:53 ` Alberto Munoz
2003-11-03 18:23 ` Jack Steiner
2003-11-03 18:42 ` Alberto Munoz
2003-11-03 19:28 ` Jack Steiner
2003-11-03 23:09 ` Alberto Munoz
2003-11-05  4:11 ` Greg Banks
2003-11-05 17:00 ` Luck, Tony
2003-11-05 17:14 ` Alberto Munoz
2003-11-05 17:30 ` Matthew Wilcox
2003-11-05 17:37 ` Alberto Munoz
2003-11-06 12:03 ` Hidetoshi Seto
2003-11-06 14:23 ` Matthias Fouquet-Lapar
2003-11-06 19:09 ` Luck, Tony
2003-11-07  9:58 ` Hidetoshi Seto
2003-11-07 10:52 ` Matthias Fouquet-Lapar
2003-11-08  1:15 ` Luck, Tony
2003-11-08  7:36 ` Matthias Fouquet-Lapar
2003-11-10 10:33 ` Hidetoshi Seto

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=marc-linux-ia64-106766923419071@msgid-missing \
    --to=mfl@kernel.paris.sgi.com \
    --cc=linux-ia64@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox