Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030940AbbD1SiZ (ORCPT ); Tue, 28 Apr 2015 14:38:25 -0400 Received: from relay1.sgi.com ([192.48.180.66]:54581 "EHLO relay.sgi.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030639AbbD1SiW (ORCPT ); Tue, 28 Apr 2015 14:38:22 -0400 Message-ID: <553FD39C.2070503@sgi.com> Date: Tue, 28 Apr 2015 13:38:20 -0500 From: nzimmer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Pekka Enberg , Mel Gorman CC: Andrew Morton , Dave Hansen , Waiman Long , Scott Norton , Daniel J Blueman , Linux-MM , LKML Subject: Re: [PATCH 0/13] Parallel struct page initialisation v4 References: <1430231830-7702-1-git-send-email-mgorman@suse.de> In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [128.162.233.123] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2143 Lines: 51 On an older 8 TB box with lots and lots of cpus the boot time, as measure from grub to login prompt, the boot time improved from 1484 seconds to exactly 1000 seconds. I have time on 16 TB box tonight and a 12 TB box thursday and will hopefully have more numbers then. On 04/28/2015 11:06 AM, Pekka Enberg wrote: > On Tue, Apr 28, 2015 at 5:36 PM, Mel Gorman wrote: >> Struct page initialisation had been identified as one of the reasons why >> large machines take a long time to boot. Patches were posted a long time ago >> to defer initialisation until they were first used. This was rejected on >> the grounds it should not be necessary to hurt the fast paths. This series >> reuses much of the work from that time but defers the initialisation of >> memory to kswapd so that one thread per node initialises memory local to >> that node. >> >> After applying the series and setting the appropriate Kconfig variable I >> see this in the boot log on a 64G machine >> >> [ 7.383764] kswapd 0 initialised deferred memory in 188ms >> [ 7.404253] kswapd 1 initialised deferred memory in 208ms >> [ 7.411044] kswapd 3 initialised deferred memory in 216ms >> [ 7.411551] kswapd 2 initialised deferred memory in 216ms >> >> On a 1TB machine, I see >> >> [ 8.406511] kswapd 3 initialised deferred memory in 1116ms >> [ 8.428518] kswapd 1 initialised deferred memory in 1140ms >> [ 8.435977] kswapd 0 initialised deferred memory in 1148ms >> [ 8.437416] kswapd 2 initialised deferred memory in 1148ms >> >> Once booted the machine appears to work as normal. Boot times were measured >> from the time shutdown was called until ssh was available again. In the >> 64G case, the boot time savings are negligible. On the 1TB machine, the >> savings were 16 seconds. > FWIW, > > Acked-by: Pekka Enberg > > for the whole series. > > - Pekka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/