Date: Mon, 12 Jan 2015 19:43:22 +0000 From: "Pokala, Ravi" <rpokala@panasas.com> To: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: [PATCH] Display progress during getmemsize() so the kernel doesn't look like it hanged Message-ID: <D0D9354E.129583%rpokala@panasas.com>
next in thread | raw e-mail | index | archive | help
-----Original Message-----
>Date: Mon, 12 Jan 2015 00:27:18 -0500
>From: Allan Jude <allanjude@freebsd.org>
>To: freebsd-hackers@freebsd.org
>Subject: Re: [PATCH] Display progress during getmemsize() so the
> kernel doesn't look like it hanged
>Message-ID: <54B35B36.4040504@freebsd.org>
>Content-Type: text/plain; charset=3D"windows-1252"
>
>On 2015-01-12 00:24, Pokala, Ravi wrote:
>> Hi folks,
>>=20
>> 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.
>>=20
>> Thanks,
>>=20
>> Ravi
>>=20
>>=20
>>
>>... =20
>>=20
>>=20
>>
>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=3D0 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=3D0?
You're right; when I set hw.memtest.tests=3D0, 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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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 =3D ((1024 * 1024) / PAGE_SIZE);
+ int PAGES_PER_GB =3D (PAGES_PER_MB * 1024);
=20
bzero(physmap, sizeof(physmap));
basemem =3D 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 =3D 0;
for (i =3D 0; i <=3D physmap_idx; i +=3D 2) {
vm_paddr_t end;
=20
@@ -1661,6 +1666,14 @@
int tmp, page_bad, full;
int *ptr =3D (int *)CADDR1;
=20
+ /*
+ * Print a "." every GB, to show we're making progress
+ */
+ page_counter++;
+ if ((page_counter % PAGES_PER_GB) =3D=3D 0) {
+ printf(".");
+ }
+
full =3D 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 =3D 0;
invltlb();
=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D0D9354E.129583%rpokala>