[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <520E5517.9070606@intel.com>
Date: Fri, 16 Aug 2013 09:36:39 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Nathan Zimmer <nzimmer@....com>
CC: hpa@...or.com, mingo@...nel.org, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, holt@....com, rob@...dley.net, travis@....com,
daniel@...ascale-asia.com, akpm@...ux-foundation.org,
gregkh@...uxfoundation.org, yinghai@...nel.org, mgorman@...e.de
Subject: Re: [RFC v3 0/5] Transparent on-demand struct page initialization
embedded in the buddy allocator
Hey Nathan,
Could you post your boot timing patches? My machines are much smaller
than yours, but I'm curious how things behave here as well.
I did some very imprecise timings (strace -t on a telnet attached to the
serial console). The 'struct page' initializations take about a minute
of boot time for me to do 1TB across 8 NUMA nodes (this is a glueless
QPI system[1]). My _quick_ calculations look like it's 2x as fast to
initialize node0's memory vs. the other nodes, and boot time is
increased by a second for about every 30G of memory we add.
So even with nothing else fancy, we could get some serious improvements
from just doing the initialization locally.
[1] We call anything using pure QPI without any other circuitry for the
NUMA interconnects to be "glueless"
--
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/
Powered by blists - more mailing lists