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

[Lars Engels]

On Mon, Jan 12, 2015 at 12:27:18AM -0500, Allan Jude wrote:
> 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
> > 
> > 
> > Index: sys/amd64/amd64/machdep.c
> > ===================================================================
> > --- sys/amd64/amd64/machdep.c	(revision 276903)
> > +++ sys/amd64/amd64/machdep.c	(working copy)
> > @@ -1575,6 +1575,9 @@
> >  	u_long physmem_start, physmem_tunable, memtest;
> >  	pt_entry_t *pte;
> >  	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;
> > @@ -1678,6 +1681,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;
> >  
> > @@ -1688,6 +1693,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.
> > @@ -1792,6 +1805,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"
> > 
> 
> Which version(s) of FreeBSD were you seeing this delay on?
> 
> 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?

This feature is useful for everyone who has it set to 1, if they know
about it or not. So it's a very useful feature.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 603 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20150113/5b49e21f/attachment.sig>