public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: Ben Woodard <woodard@redhat.com>
To: linux-ia64@vger.kernel.org
Subject: RE: new utility for decoding salinfo records
Date: Tue, 11 Jan 2005 21:03:22 +0000	[thread overview]
Message-ID: <1105477402.22104.158.camel@quince.llnl.gov> (raw)
In-Reply-To: <1105458388.22104.7.camel@quince.llnl.gov>

On Tue, 2005-01-11 at 12:53, Mark Goodwin wrote:
> On Tue, 11 Jan 2005, Ben Woodard wrote:
> > ...
> > 3) If there is a real failure, it shows up really quickly. We have all
> > sorts of SBEs or MBEs. In that case we replace the DIMM immediately.
> >
> > So does anyone with "normal world" experience have any suggestions on
> > how I should take into account the various perspectives?
> >
> > Do other people consider the isolated SBE a problem?
> 
> considered normal, fully recoverable.
> 
> >
> > Do other people consider 1SBE/hr on a DIMM a real problem that needs to
> > be fixed?
> 
> this is a concern if the failing DIMM ends up with uncorrectable MBEs.
> Do you have any evidence that a relatively high rate of SBEs on a
> DIMM can be used to predict that MBEs are likely to start occurring?

No quite the contrary. We believed rates of SBEs in the neighborhood of
1/hr would ultimately lead to MBEs but further testing has shown that we
really don't see DIMMS with SBEs turing in MBEs.

We did replace plenty of DIMMs which did have higher rates of SBEs
simply because it takes computational time to handle a SBE and we feared
it would introduce additional time in tightly coupled in scientific
codes.

> Memory hot-unplug or a bad-page reserving strategy based on such
> prediction may be interesting.
> 
> -- Mark


  parent reply	other threads:[~2005-01-11 21:03 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-11 15:46 new utility for decoding salinfo records Ben Woodard
2005-01-11 19:03 ` David Mosberger
2005-01-11 19:49 ` Luck, Tony
2005-01-11 20:25 ` David Mosberger
2005-01-11 20:26 ` Ben Woodard
2005-01-11 20:53 ` Mark Goodwin
2005-01-11 21:03 ` Ben Woodard [this message]
2005-01-11 21:12 ` Ben Woodard
2005-01-11 21:22 ` Russ Anderson
2005-01-11 21:23 ` Luck, Tony
2005-01-11 21:25 ` David Mosberger
2005-01-11 21:36 ` David Mosberger
2005-01-11 21:36 ` Matthias Fouquet-Lapar
2005-01-11 21:37 ` Ben Woodard
2005-01-11 21:42 ` David Mosberger
2005-01-11 21:58 ` Russ Anderson
2005-01-11 22:02 ` David Mosberger
2005-01-11 22:26 ` Matthias Fouquet-Lapar
2005-01-12  4:10 ` Keith Owens
2005-01-12  6:08 ` Luck, Tony
2005-01-12  6:43 ` Keith Owens
2005-01-12  9:34 ` Matthias Fouquet-Lapar
2005-01-12 16:57 ` Ben Woodard
2005-01-12 20:46 ` Keith Owens

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=1105477402.22104.158.camel@quince.llnl.gov \
    --to=woodard@redhat.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