From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965393AbdCVSD5 (ORCPT ); Wed, 22 Mar 2017 14:03:57 -0400 Received: from mail.skyhub.de ([5.9.137.197]:35748 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934813AbdCVSDs (ORCPT ); Wed, 22 Mar 2017 14:03:48 -0400 Date: Wed, 22 Mar 2017 19:03:39 +0100 From: Borislav Petkov To: "Luck, Tony" Cc: X86 ML , linux-edac , LKML Subject: Re: [PATCH 3/4] RAS: Add a Corrected Errors Collector Message-ID: <20170322180339.GC15888@nazgul.tnic> References: <20170309100818.15466-1-bp@alien8.de> <20170309100818.15466-4-bp@alien8.de> <20170320224824.GA27165@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20170320224824.GA27165@intel.com> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 20, 2017 at 03:48:24PM -0700, Luck, Tony wrote: > You added "count_threshold" for me ... so the condition isn't quite "overflows" > like it was in the early versions. It is a max count which, when reached, causes the soft offline attempt. What did you mean with "overflows" exactly then? > We may need to give some thought on what to do if the attempt to offline > the page fails (e.g. because the page belongs to the kernel). Right now > you delete it from the list, but we will see more errors as the page is > still in use. Eventually the counter will hit count_threshold and we will > try to offline again. Rinse, repeat. Well, what *is* there we can do? If the offlining code can't offline it, there's not a whole lot we *can* do. The error would keep repeating as a corrected error, rinse, repeat and we will keep trying to offline containing page. That is, until it degrades to an uncorrectable error and then we're dead. Either way, the collector can't really do anything about it. This would be beyond its functionality anyway. IMO. > Someone also recently sent me a log from a machine with corrected errors > in over 9000 unique addresses. Need a parameter to allocate more than one > page for the collector, or a way to grow the space. Well, so even with the amount of unique addresses higher than the CEC slots, we should be able to deal with them ok: the moment we enter more than CLEAN_ELEMS pfns, we will trigger a spring cleaning which will degrade the already logged errors. Once the array is filled up, we will replace the LRU pfn with the new one. And so on. And this way it would fulfill its purpose of *not* generating error records into the decoding chain after it. If one of those 9000 errors overflows, we will try to offline the page. Either way we work as advertized. Lemme try to write a small script exercising exactly that scenario to see whether I'm actually not talking crap here :-) -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. --