Re: [PATCH v7 04/25] ACPI / APEI: Make hest.c manage the estatus memory pool
From: Borislav Petkov <bp@alien8.de>
Date: 2018-12-11 16:48:13
Also in:
kvmarm, linux-acpi, linux-mm
On Mon, Dec 03, 2018 at 06:05:52PM +0000, James Morse wrote:
ghes.c has a memory pool it uses for the estatus cache and the estatus queue. The cache is initialised when registering the platform driver. For the queue, an NMI-like notification has to grow/shrink the pool as it is registered and unregistered. This is all pretty noisy when adding new NMI-like notifications, it would be better to replace this with a static pool size based on the number of users. As a precursor, move the call that creates the pool from ghes_init(), into hest.c. Later this will take the number of ghes entries and consolidate the queue allocations. Remove ghes_estatus_pool_exit() as hest.c doesn't have anywhere to put this. The pool is now initialised as part of ACPI's subsys_initcall(): (acpi_init(), acpi_scan_init(), acpi_pci_root_init(), acpi_hest_init()) Before this patch it happened later as a GHES specific device_initcall(). Signed-off-by: James Morse <james.morse@arm.com> --- drivers/acpi/apei/ghes.c | 33 ++++++--------------------------- drivers/acpi/apei/hest.c | 5 +++++ include/acpi/ghes.h | 2 ++ 3 files changed, 13 insertions(+), 27 deletions(-)
...
quoted hunk ↗ jump to hunk
diff --git a/drivers/acpi/apei/hest.c b/drivers/acpi/apei/hest.c index b1e9f81ebeea..da5fabaeb48f 100644 --- a/drivers/acpi/apei/hest.c +++ b/drivers/acpi/apei/hest.c@@ -32,6 +32,7 @@ #include <linux/io.h> #include <linux/platform_device.h> #include <acpi/apei.h> +#include <acpi/ghes.h> #include "apei-internal.h"@@ -200,6 +201,10 @@ static int __init hest_ghes_dev_register(unsigned int ghes_count) if (!ghes_arr.ghes_devs) return -ENOMEM; + rc = ghes_estatus_pool_init(); + if (rc) + goto out;
Right, this happens before...
+ rc = apei_hest_parse(hest_parse_ghes, &ghes_arr);
... this but do we even want to do any memory allocations if we don't
have any HEST tables or we've been disabled by hest_disable?
IOW, we should swap those two calls, methinks.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel