linux-kernel - Re: [RFC 0/2] Delay initializing of large sections of memory

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 21 Jun 2013 11:44:34 -0700
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Yinghai Lu <yinghai@...nel.org>
Cc:	Nathan Zimmer <nzimmer@....com>, Robin Holt <holt@....com>,
	Mike Travis <travis@....com>, Rob Landley <rob@...dley.net>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	the arch/x86 maintainers <x86@...nel.org>,
	linux-doc@...r.kernel.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RFC 0/2] Delay initializing of large sections of memory

On Fri, Jun 21, 2013 at 11:36:21AM -0700, Yinghai Lu wrote:
> On Fri, Jun 21, 2013 at 9:25 AM, Nathan Zimmer <nzimmer@....com> wrote:
> > This rfc patch set delays initializing large sections of memory until we have
> > started cpus.  This has the effect of reducing startup times on large memory
> > systems.  On 16TB it can take over an hour to boot and most of that time
> > is spent initializing memory.
> 
> One hour on system with 16T ram? BIOS or OS?
> 
> I use wall clock to check bootime on one system with 3T and 16 pcie cards,
> Linus only takes about 3m and 30 seconds from bootloader.
> 
> wonder if you boot delay is with so many cpu get onlined in serialized mode.
> 
> so can you try boot your system with "maxcpus=128" to get the boot time with
> wall clock ?

Why use the "wall clock" when we have the wonderful bootchart tools and
scripts that do this all for you, and can tell you exactly what part of
the kernel is taking what time, to help with fixing issues like this?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/