From owner-freebsd-arch@FreeBSD.ORG Wed Mar 23 10:30:12 2011 Return-Path: Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 980F3106564A; Wed, 23 Mar 2011 10:30:12 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1B7FC8FC0A; Wed, 23 Mar 2011 10:30:11 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id p2NATtf4090499; Wed, 23 Mar 2011 11:30:10 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id p2NATtwg090498; Wed, 23 Mar 2011 11:29:55 +0100 (CET) (envelope-from olli) Date: Wed, 23 Mar 2011 11:29:55 +0100 (CET) Message-Id: <201103231029.p2NATtwg090498@lurza.secnetix.de> From: Oliver Fromme To: freebsd-arch@FreeBSD.ORG, bz@FreeBSD.ORG In-Reply-To: X-Newsgroups: list.freebsd-arch User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.5 (lurza.secnetix.de [127.0.0.1]); Wed, 23 Mar 2011 11:30:10 +0100 (CET) Cc: Subject: Re: kernel memory checks on boot vs. boot time X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 10:30:12 -0000 Bjoern A. Zeeb wrote: > as part of the i386/pc98/amd64 boot process we are doing some basic > memory testing, mapping pages and running a couple of pattern > write/read tests on the first bytes (see getmemsize() implmentations). > [...] > With the growing number of memory this can lead to a significant > fraction of kernel startup time on amd64 (~40s delays observed with > 96G of RAM). Looping over the pages, but not mapping them and not > running the pattern tests reduces this significantly (to single digit > numbers of seconds). > [...] > Not wanting to remove them but maybe make more use of them in the > future (as we do not report any problems we find currently) I'd suggest > to introduce a tunable to disable/enable them, say > > hw.run_memtest +1 for introducing a tunable. I have also noticed the boot delay on server machines with lots of memory (all of them are amd64, FWIW). Co-workers have noticed it, too, causing some funny remarks. :-) By the way, "big" servers are not the only machines affected. I have recently built a small HTPC based on an Atom 330 (it supports amd64) with 4 GB RAM. Unfortunately, suspend + resume doesn't work, so I have to shutdown and boot it fully each time I want to use it. Needless to say, I would like to squeeze every second from the boot process. Currently, the time between the transition from bootloader to kernel and the start of init(8) is by far the largest slice of the total boot time. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "What is this talk of 'release'? We do not make software 'releases'. Our software 'escapes', leaving a bloody trail of designers and quality assurance people in its wake."