From: Borislav Petkov <bp@alien8.de>
To: Shiju Jose <shiju.jose@huawei.com>
Cc: linux-edac@vger.kernel.org, linux-acpi@vger.kernel.org,
linux-kernel@vger.kernel.org, james.morse@arm.com,
mchehab+huawei@kernel.org, tony.luck@intel.com,
rjw@rjwysocki.net, lenb@kernel.org, rrichter@marvell.com,
linuxarm@huawei.com, xuwei5@huawei.com,
jonathan.cameron@huawei.com, john.garry@huawei.com,
tanxiaofei@huawei.com, shameerali.kolothum.thodi@huawei.com,
salil.mehta@huawei.com
Subject: Re: [RFC PATCH 1/2] EDAC/ghes: Add EDAC device for the CPU caches
Date: Thu, 31 Dec 2020 17:44:09 +0100 [thread overview]
Message-ID: <20201231164409.GC4504@zn.tnic> (raw)
In-Reply-To: <20201208172959.1249-2-shiju.jose@huawei.com>
On Tue, Dec 08, 2020 at 05:29:58PM +0000, Shiju Jose wrote:
> The corrected error count on the CPU caches required
> reporting to the user-space for the predictive failure
> analysis. For this purpose, add an EDAC device and device
> blocks for the CPU caches found.
> The cache's corrected error count would be stored in the
> /sys/devices/system/edac/cpu/cpu*/cache*/ce_count.
This still doesn't begin to explain why the kernel needs this. I had
already asked whether errors in CPU caches are something which happen
often enough so that software should count them but nothing came. So pls
justify first why this wants to be added to the kernel.
> diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
> index 7a47680d6f07..c73eeab27ac9 100644
> --- a/drivers/edac/Kconfig
> +++ b/drivers/edac/Kconfig
> @@ -74,6 +74,16 @@ config EDAC_GHES
>
> In doubt, say 'Y'.
>
> +config EDAC_GHES_CPU_ERROR
> + bool "EDAC device for reporting firmware-first BIOS detected CPU error count"
Why a separate Kconfig item?
> + depends on EDAC_GHES
> + help
> + EDAC device for the firmware-first BIOS detected CPU error count reported
Well this is not what it is doing - you're talking about cache errors.
"CPU errors" can be a lot more than just cache errors.
> +static void ghes_edac_create_cpu_device(struct device *dev)
> +{
> + int cpu;
> + struct cpu_cacheinfo *this_cpu_ci;
> +
> + /*
> + * Find the maximum number of caches present in the CPU heirarchy
> + * among the online CPUs.
> + */
> + for_each_online_cpu(cpu) {
> + this_cpu_ci = get_cpu_cacheinfo(cpu);
> + if (!this_cpu_ci)
> + continue;
> + if (max_number_of_caches < this_cpu_ci->num_leaves)
> + max_number_of_caches = this_cpu_ci->num_leaves;
So this is counting the number of cache levels on the system? So you
want to count the errors per cache levels?
> + }
> + if (!max_number_of_caches)
> + return;
> +
> + /*
> + * EDAC device interface only supports creating the CPU cache hierarchy for alls
> + * the CPUs together. Thus need to allocate cpu_edac_block_list for the
> + * max_number_of_caches among all the CPUs irrespective of the number of caches
> + * per CPU might vary.
> + */
So this is lumping all the caches together into a single list? What for?
To untangle to the proper ones when the error gets reported?
Have you heard of percpu variables?
> @@ -624,6 +787,10 @@ int ghes_edac_register(struct ghes *ghes, struct device *dev)
> ghes_pvt = pvt;
> spin_unlock_irqrestore(&ghes_lock, flags);
>
> +#if defined(CONFIG_EDAC_GHES_CPU_ERROR)
> + ghes_edac_create_cpu_device(dev);
> +#endif
> +
Init stuff belongs into ghes_scan_system().
...
Ok, I've seen enough. "required reporting to the user-space for the
predictive failure analysis." is not even trying to explain *why* you're
doing this, what *actual* problem it is addressing and why should the
kernel get it.
And without a proper problem definition of what you're trying to solve,
this is not going anywhere.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
next prev parent reply other threads:[~2020-12-31 16:45 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-08 17:29 [RFC PATCH 0/2] EDAC/ghes: Add EDAC device for recording the CPU error count Shiju Jose
2020-12-08 17:29 ` [RFC PATCH 1/2] EDAC/ghes: Add EDAC device for the CPU caches Shiju Jose
2020-12-31 16:44 ` Borislav Petkov [this message]
2021-01-15 11:06 ` Shiju Jose
2021-01-18 18:36 ` Borislav Petkov
2021-01-19 10:04 ` Shiju Jose
2021-01-19 10:16 ` Borislav Petkov
2020-12-08 17:29 ` [RFC PATCH 2/2] ACPI / APEI: Add reporting ARM64 CPU cache corrected error count Shiju Jose
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=20201231164409.GC4504@zn.tnic \
--to=bp@alien8.de \
--cc=james.morse@arm.com \
--cc=john.garry@huawei.com \
--cc=jonathan.cameron@huawei.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=mchehab+huawei@kernel.org \
--cc=rjw@rjwysocki.net \
--cc=rrichter@marvell.com \
--cc=salil.mehta@huawei.com \
--cc=shameerali.kolothum.thodi@huawei.com \
--cc=shiju.jose@huawei.com \
--cc=tanxiaofei@huawei.com \
--cc=tony.luck@intel.com \
--cc=xuwei5@huawei.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