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 19:15:32 +0200 [thread overview]
Message-ID: <20190422171532.GH21457@zn.tnic> (raw)
In-Reply-To: <3908561D78D1C84285E8C5FCA982C28F7E90A404@ORSMSX104.amr.corp.intel.com>
On Mon, Apr 22, 2019 at 03:59:16PM +0000, Luck, Tony wrote:
> > Err, this all sounds to me like the storm detection code should
> > *automatically* disable the CEC in such cases, I'd say.
>
> Sounds good. But we should distinguish storms that have many different
> addresses from storms that just ping a few addresses. CEC will see counts
> hit the threshold in the latter case, but it might not be able to take the pages
> offline (because they are locked, or in-use by kernel).
>
> So I think the change might be to the return value from NOTIFY_STOP to NOTIFY_DONE
> ... but only if we are in the middle of a storm AND the CEC array is full.
Well, regardless of this specific use case, isn't that a generic enough
action that we should do always? I mean, the aspect of falling back to
logging to external agent.
However, currently we don't signal that the CEC is full - we simply
remove the LRU element in cec_add_elem() before we insert the new one.
We can either return a specific retval to say, CEC is full and we had to
delete an elem or we can add a cec_is_full() accessor...
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
next prev parent reply other threads:[~2019-04-22 17:15 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 [this message]
2019-04-22 17:44 ` Luck, Tony
2019-04-22 18:08 ` Borislav Petkov
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=20190422171532.GH21457@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 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.