On Wed, 6 Jul 2022 16:59:21 -0700 "Zach O'Keefe" <zokeefe@xxxxxxxxxx> wrote:
> Modularize hugepage collapse by introducing struct collapse_control.
> This structure serves to describe the properties of the requested
> collapse, as well as serve as a local scratch pad to use during the
> collapse itself.
>
> Start by moving global per-node khugepaged statistics into this
> new structure. Note that this structure is still statically allocated
> since CONFIG_NODES_SHIFT might be arbitrary large, and stack-allocating
> a MAX_NUMNODES-sized array could cause -Wframe-large-than= errors.
>
> Signed-off-by: Zach O'Keefe <zokeefe@xxxxxxxxxx>
> ---
> mm/khugepaged.c | 87 ++++++++++++++++++++++++++++---------------------
> 1 file changed, 50 insertions(+), 37 deletions(-)
>
> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> index 196eaadbf415..f1ef02d9fe07 100644
> --- a/mm/khugepaged.c
> +++ b/mm/khugepaged.c
> @@ -85,6 +85,14 @@ static struct kmem_cache *mm_slot_cache __read_mostly;
>
> #define MAX_PTE_MAPPED_THP 8
>
> +struct collapse_control {
> + /* Num pages scanned per node */
> + int node_load[MAX_NUMNODES];
Does this actually need to be 32-bit? Looking at the current code I'm
suspecting that khugepaged_node_load[] could be a ushort?
[And unsigned int would be more appropriate, but we always do that :(]
