From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 05:24:41 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 40161219 for ; Mon, 12 Jan 2015 05:24:41 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0053.outbound.protection.outlook.com [157.56.110.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EC37E61A for ; Mon, 12 Jan 2015 05:24:40 +0000 (UTC) Received: from BN3PR0801MB0931.namprd08.prod.outlook.com (25.160.184.25) by BN3PR0801MB0929.namprd08.prod.outlook.com (25.160.184.23) with Microsoft SMTP Server (TLS) id 15.1.53.17; Mon, 12 Jan 2015 05:24:31 +0000 Received: from BN3PR0801MB0931.namprd08.prod.outlook.com ([25.160.184.25]) by BN3PR0801MB0931.namprd08.prod.outlook.com ([25.160.184.25]) with mapi id 15.01.0053.000; Mon, 12 Jan 2015 05:24:31 +0000 From: "Pokala, Ravi" To: "freebsd-hackers@freebsd.org" Subject: [PATCH] Display progress during getmemsize() so the kernel doesn't look like it hanged Thread-Topic: [PATCH] Display progress during getmemsize() so the kernel doesn't look like it hanged Thread-Index: AQHQLigK82/0oK+YUEaY/TDDejfaPg== Date: Mon, 12 Jan 2015 05:24:31 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [24.6.178.251] authentication-results: spf=none (sender IP is ) smtp.mailfrom=rpokala@panasas.com; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:BN3PR0801MB0929; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BN3PR0801MB0929; x-forefront-prvs: 0454444834 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(6009001)(164054003)(199003)(189002)(107886001)(102836002)(40100003)(122556002)(106356001)(68736005)(229853001)(92566002)(2351001)(450100001)(62966003)(77156002)(99286002)(66066001)(110136001)(54356999)(97736003)(105586002)(2656002)(106116001)(2900100001)(46102003)(83506001)(50986999)(36756003)(64706001)(86362001)(87936001)(101416001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0801MB0929; H:BN3PR0801MB0931.namprd08.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: panasas.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-ID: <6C49B7CD126D414E97FF45E1427CC3EC@namprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: panasas.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2015 05:24:31.2380 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: acf01c9d-c699-42af-bdbb-44bf582e60b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0801MB0929 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 05:24:41 -0000 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 =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 --- 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 =3D ((1024 * 1024) / PAGE_SIZE); + int PAGES_PER_GB =3D (PAGES_PER_MB * 1024); =20 bzero(physmap, sizeof(physmap)); basemem =3D 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 =3D 0; for (i =3D 0; i <=3D physmap_idx; i +=3D 2) { vm_paddr_t end; =20 @@ -1688,6 +1693,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. @@ -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 =3D 0; invltlb(); =20