[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20230321130155.dfd4ba94d093faa90213182b@linux-foundation.org>
Date: Tue, 21 Mar 2023 13:01:55 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Tomas Mudrunka <tomas.mudrunka@...il.com>
Cc: linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, rppt@...nel.org, linux-doc@...r.kernel.org,
corbet@....net
Subject: Re: [PATCH v2] Add results of early memtest to /proc/meminfo
On Tue, 21 Mar 2023 11:34:30 +0100 Tomas Mudrunka <tomas.mudrunka@...il.com> wrote:
> Currently the memtest results were only presented in dmesg.
> This adds /proc/meminfo entry which can be easily used by scripts.
Looks good to me, thanks. But the changelog still doesn't explain why
we should make this change. I grabbed that from your other email and
used the below as the changelog:
: Currently the memtest results were only presented in dmesg.
:
: When running a large fleet of devices without ECC RAM it's currently not
: easy to do bulk monitoring for memory corruption. You have to parse
: dmesg, but that's a ring buffer so the error might disappear after some
: time. In general I do not consider dmesg to be a great API to query RAM
: status.
:
: In several companies I've seen such errors remain undetected and cause
: issues for way too long. So I think it makes sense to provide a monitoring
: API, so that we can safely detect and act upon them.
:
: This adds /proc/meminfo entry which can be easily used by scripts.
Powered by blists - more mailing lists