From owner-freebsd-current@FreeBSD.ORG Sat Nov 16 18:45:24 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 37878D53 for ; Sat, 16 Nov 2013 18:45:24 +0000 (UTC) Received: from mail.jrv.org (adsl-70-243-84-11.dsl.austtx.swbell.net [70.243.84.11]) by mx1.freebsd.org (Postfix) with ESMTP id 0B8322EF7 for ; Sat, 16 Nov 2013 18:45:23 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.jrv.org (Postfix) with ESMTP id 09AC012405B; Sat, 16 Nov 2013 12:37:08 -0600 (CST) X-Virus-Scanned: amavisd-new at zimbra.housenet.jrv Received: from mail.jrv.org ([127.0.0.1]) by localhost (zimbra.housenet.jrv [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qu0FGFGYlvMI; Sat, 16 Nov 2013 12:37:07 -0600 (CST) Received: from [10.0.2.15] (cielo.housenet.jrv [192.168.3.141]) by mail.jrv.org (Postfix) with ESMTPSA id 69B40124058; Sat, 16 Nov 2013 12:37:07 -0600 (CST) Message-ID: <5287BB44.4020104@jrv.org> Date: Sat, 16 Nov 2013 12:36:52 -0600 From: "James R. Van Artsdalen" User-Agent: Mozilla/5.0 (Windows NT 5.0; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Allan Jude Subject: Re: Slow boot with 256GB of RAM? References: <5286F670.2050305@jrv.org> <5287071B.3020209@petermann-it.de> <528786C9.9070409@allanjude.com> In-Reply-To: <528786C9.9070409@allanjude.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Nov 2013 18:45:24 -0000 On 11/16/2013 8:52 AM, Allan Jude wrote: > I see this was in the release notes for 9.0 and 8.3, but other than > that, I don't see how anyone was supposed to find out about this. > Maybe it would make sense to print 'Starting memory test, set > hw.memtest.test=0 to disable' before that starts, so anyone stuck > waiting will have a hint about what to do. It takes less effort to speed it up than to document that it is slow.. For now, in my sources, I've lengthened the testing stride to 64KB. A better fix would leave the cache on (don't fight the cache in a memory test - it is your friend! :-) and to group all writes and reads together in a larger chunk - say 16MB - so as to take advantage of write combining and cache line fetching. And add writes of address-specific values so address space aliasing can be detected.