public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: Cong Wang <xiyou.wangcong@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] RAS/CEC: Add debugfs switch to disable at run time
Date: Mon, 22 Apr 2019 20:08:31 +0200	[thread overview]
Message-ID: <20190422180831.GK21457@zn.tnic> (raw)
In-Reply-To: <20190422174415.GA21890@agluck-desk>

On Mon, Apr 22, 2019 at 10:44:15AM -0700, Luck, Tony wrote:
> Yes. Automating this would be a very good idea.

Yeah, in general integrating the CEC better with the rest of the error
chain is something we still need to discuss and do.

> In the case of many errors at different addresses we are deleting
> the entry with the lowest count. But all of the entries have low
> counts because we are just thrashing the array with many different
> addresses. In this situation a warning would be helpful.

Can we detect that situation reliably even? You can have many errors at
different addresses which have accumulated over time, due to a slow but
constant stream of errors. Dunno if that is possible though... someone
needs to analyze error occurrence patterns :-\

> But in the case where the system has been up for months and
> we very slowly accumlated logs of bit flips. The periodic
> spring cleaning means they all have generation "00", but
> we never actually drop an old entry because of age.

Yes, we drop only on insertion and when the array is full or when we
soft-offline.

> In this case dropping one entry to make space for a new one is fine
> and doesn't need any action.
>
> Perhaps we can distinguish the cases by the generation? If
> we are dropping an entry that was recently added, then it
> will still have generation "11" (or at least not "00").
> Use that to trigger an action?

That and the fact that we're in an error storm is probably a good enough
heurstic. And then when the storm subsides, we reenable it? We basically
say, error storm is over, the error rate should go back to normal so we
can stick the CEC in front of it again.

Hmmm.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

  reply	other threads:[~2019-04-22 18:08 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-18 22:02 [PATCH] RAS/CEC: Add debugfs switch to disable at run time Tony Luck
2019-04-18 22:51 ` Cong Wang
2019-04-18 23:29   ` Borislav Petkov
2019-04-18 23:58     ` Cong Wang
2019-04-19  0:26       ` Borislav Petkov
2019-04-20  5:43         ` Cong Wang
2019-04-20  9:13           ` Borislav Petkov
2019-04-20 18:18             ` Cong Wang
2019-04-20 18:47               ` Borislav Petkov
2019-04-20 19:08                 ` Cong Wang
2019-04-22 16:29                 ` Luck, Tony
2019-04-22 16:31                   ` Borislav Petkov
2019-04-22 16:43                     ` Luck, Tony
2019-04-22 17:05                       ` Borislav Petkov
2019-04-22 17:23                         ` Luck, Tony
2019-04-19  0:07     ` Luck, Tony
2019-04-19  0:29       ` Borislav Petkov
2019-04-19 15:04         ` Luck, Tony
2019-04-20  9:41           ` Borislav Petkov
2019-04-22 15:59             ` Luck, Tony
2019-04-22 17:15               ` Borislav Petkov
2019-04-22 17:44                 ` Luck, Tony
2019-04-22 18:08                   ` Borislav Petkov [this message]
2019-04-20  5:50       ` Cong Wang
2019-04-20 19:50 ` Borislav Petkov

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=20190422180831.GK21457@zn.tnic \
    --to=bp@alien8.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tony.luck@intel.com \
    --cc=xiyou.wangcong@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