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@xxxxxxx>
> ---
> drivers/acpi/apei/ghes.c | 33 ++++++---------------------------
> drivers/acpi/apei/hest.c | 5 +++++
> include/acpi/ghes.h | 2 ++
> 3 files changed, 13 insertions(+), 27 deletions(-)
...
> 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.
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
