[PATCH] Display progress during getmemsize() so the kernel doesn't look like it hanged

[Patrick Powell]

On 01/12/15 11:43, Pokala, Ravi wrote:
> -----Original Message-----
>> Date: Mon, 12 Jan 2015 00:27:18 -0500
>> From: Allan Jude <allanjude at freebsd.org>
>> To: freebsd-hackers at freebsd.org
>> Subject: Re: [PATCH] Display progress during getmemsize() so the
>> 	kernel doesn't look like it hanged
>> Message-ID: <54B35B36.4040504 at freebsd.org>
>> Content-Type: text/plain; charset="windows-1252"
>>
>> On 2015-01-12 00:24, Pokala, Ravi wrote:
>>> Hi folks,
>>>
>>> Several of us have noticed that there's a long pause at the start of
>>> booting the kernel on amd64 systems with large amounts of RAM. During
>>> This pause, the kernel is mapping in the memory ranges, but does not
>>> emit any progress indicators. Because this can take quite a while, it
>>> can look like the kernel has hung. I filed PR 196650 about this issue;
>>> this patch just prints out a dot for every GB that's mapped in. We've
>>> been using this patch for years at Panasas, and I'm hoping someone can
>>> submit it for me.
>>>
>>> Thanks,
>>>
>>> Ravi
>>>
>>>
>>>
>>> ...
>>>
>>>
>>>
>> Which version(s) of FreeBSD were you seeing this delay on?
> We first noted it with 7.2, because that's what we used on our first amd64
> systems with > 4GB RAM. We're still seeing it with 10.1.
>
>> I know older versions had it, quite badly.
>>
>> setting hw.memtest.tests=0 in /boot/loader.conf makes most of the delay
>> go away, and the default on -CURRENT is now 0 instead of 1.
>>
>> IIRC, in 10, it defaults to 1, but is switched to 0 in the case of
>> virtual machines, because touching every page of memory ruined memory
>> over-commit type features.
>>
>> Is this feature still useful with memtest.tests=0?
> You're right; when I set hw.memtest.tests=0, the pause goes away in 10.1.
> I thought it defaulted to 0 in 10.1.
>
> So that changes this slightly - could we either change the default in
> 10-STABLE, or commit the following patch against 10-STABLE?
>
> Thanks,
>
> Ravi
>
>
> Index: sys/amd64/amd64/machdep.c
> ===================================================================
> diff --git a/stable/10/sys/amd64/amd64/machdep.c
> b/stable/10/sys/amd64/amd64/machdep.c
> --- a/stable/10/sys/amd64/amd64/machdep.c	(revision 277085)
> +++ b/stable/10/sys/amd64/amd64/machdep.c	(working copy)
> @@ -1541,6 +1541,9 @@
>   	struct bios_smap *smapbase;
>   	struct efi_map_header *efihdr;
>   	quad_t dcons_addr, dcons_size;
> +	u_int32_t page_counter;
> +	int PAGES_PER_MB = ((1024 * 1024) / PAGE_SIZE);
> +	int PAGES_PER_GB = (PAGES_PER_MB * 1024);
>   
>   	bzero(physmap, sizeof(physmap));
>   	basemem = 0;
> @@ -1651,6 +1654,8 @@
>   	 * physmap is in bytes, so when converting to page boundaries,
>   	 * round up the start address and round down the end address.
>   	 */
> +	printf("Mapping system memory");
> +	page_counter = 0;
>   	for (i = 0; i <= physmap_idx; i += 2) {
>   		vm_paddr_t end;
>   
> @@ -1661,6 +1666,14 @@
>   			int tmp, page_bad, full;
>   			int *ptr = (int *)CADDR1;
>   
> +			/*
> +			 * Print a "." every GB, to show we're making progress
> +			 */
> +			page_counter++;
> +			if ((page_counter % PAGES_PER_GB) == 0) {
> +				printf(".");
> +			}
> +
>   			full = FALSE;
>   			/*
>   			 * block out kernel memory as not available.
> @@ -1765,6 +1778,9 @@
>   				break;
>   		}
>   	}
> +	printf("\nMapped %d GB + %d MB total\n",
> +	    (page_counter / PAGES_PER_GB),
> +	    ((page_counter % PAGES_PER_GB) / PAGES_PER_MB));
>   	*pte = 0;
>   	invltlb();
>   
>
>
>
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>
I like the idea of the busy dots.  It would make new sysadmins doing 
installs feel much happier when the system pauses for a couple of 
minutes during boot.

Patrick ("Its dead, Jim!"  "Its not dead, its just checking memory.") Powell

-- 
Patrick Powell                 Astart Technologies
papowell at astart.com            1530 Jamacha Rd, Suite X
Network and System             San Diego, CA 92019
   Consulting                   858-874-6543 FAX 858-751-2435
Web: www.astart.com