kernel memory checks on boot vs. boot time

Oliver Fromme olli at
Wed Mar 23 10:30:12 UTC 2011

Bjoern A. Zeeb <bz at> 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 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:

"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."

More information about the freebsd-arch mailing list