|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] mm/page_alloc: add bootscrub=idle cmdline option
>>> On 03.10.18 at 12:28, <sergey.dyasli@xxxxxxxxxx> wrote:
> Scrubbing RAM during boot may take a long time on machines with lots
> of RAM. Add 'idle' option which marks all pages dirty initially so they
> would eventually be scrubbed in idle-loop on every online CPU.
>
> Performance of idle-loop scrubbing is worse than bootscrub but it's
> guaranteed that the allocator will return scrubbed pages by doing
> eager scrubbing during allocation (unless MEMF_no_scrub was provided).
I've commented on this before: Without clarifying what "performance"
means in this context, the statement's truth cannot be verified. To
certain (many?) people, performance in the context of booting a system
may mean the time it takes until the system is fully up. I think idle
scrubbing helps this rather than making it worse.
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -227,7 +227,7 @@ that byte `0x12345678` is bad, you would place
> `badpage=0x12345` on
> Xen's command line.
>
> ### bootscrub
> -> `= <boolean>`
> +> `= <boolean> | idle`
>
> > Default: `true`
Any reason not to make "idle" the default? Iirc that was the plan anyway.
> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -161,8 +161,32 @@ string_param("badpage", opt_badpage);
> /*
> * no-bootscrub -> Free pages are not zeroed during boot.
> */
> -static bool_t opt_bootscrub __initdata = 1;
> -boolean_param("bootscrub", opt_bootscrub);
> +enum {
> + BOOTSCRUB_OFF = 0,
> + BOOTSCRUB_ON,
> + BOOTSCRUB_IDLE,
> +};
> +static int __read_mostly opt_bootscrub = BOOTSCRUB_ON;
Why "int" when you've just made yourself an enum?
> +static int __init parse_bootscrub_param(const char *s)
> +{
> + if ( *s == '\0' )
> + return 0;
> +
> + if ( !strcmp(s, "idle") )
> + opt_bootscrub = BOOTSCRUB_IDLE;
> + else
> + opt_bootscrub = parse_bool(s, NULL);
> +
> + if ( opt_bootscrub < 0 )
Can you please follow the model used elsewhere, where parse_bool()
gets called first? Also can "bootscrub" alone please have the same
meaning as "bootscrub=yes"?
> + {
> + opt_bootscrub = BOOTSCRUB_ON;
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +custom_param("bootscrub", parse_bootscrub_param);
No blank line between function and its own custom_param()
please.
> @@ -1763,7 +1787,8 @@ static void init_heap_pages(
> nr_pages -= n;
> }
>
> - free_heap_pages(pg + i, 0, scrub_debug);
> + free_heap_pages(pg + i, 0, scrub_debug ||
> + opt_bootscrub == BOOTSCRUB_IDLE);
So this is the hunk explaining why the variable can't be __initdata.
The question though is whether the resulting post-init behavior
is actually correct; it's certainly odd for a boot related option to
have an effect post-boot as well.
> @@ -2039,8 +2064,11 @@ void __init heap_init_late(void)
> */
> setup_low_mem_virq();
>
> - if ( opt_bootscrub )
> + if ( opt_bootscrub == BOOTSCRUB_ON )
> scrub_heap_pages();
> + else if ( opt_bootscrub == BOOTSCRUB_IDLE )
> + printk("Scrubbing Free RAM on %d nodes in background\n",
> + num_online_nodes());
switch()? And is the reference to the node count really meaningful
in the logged message?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |