[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <51C4C5F3.3050800@sgi.com>
Date: Fri, 21 Jun 2013 14:30:27 -0700
From: Mike Travis <travis@....com>
To: Greg KH <gregkh@...uxfoundation.org>
CC: Yinghai Lu <yinghai@...nel.org>, "H. Peter Anvin" <hpa@...or.com>,
Nathan Zimmer <nzimmer@....com>, Robin Holt <holt@....com>,
Rob Landley <rob@...dley.net>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.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 6/21/2013 11:50 AM, Greg KH wrote:
> On Fri, Jun 21, 2013 at 11:44:22AM -0700, Yinghai Lu wrote:
>> On Fri, Jun 21, 2013 at 10:03 AM, H. Peter Anvin <hpa@...or.com> wrote:
>>> On 06/21/2013 09:51 AM, Greg KH wrote:
>>>
>>> I suspect the cutoff for this should be a lot lower than 8 TB even, more
>>> like 128 GB or so. The only concern is to not set the cutoff so low
>>> that we can end up running out of memory or with suboptimal NUMA
>>> placement just because of this.
>>
>> I would suggest another way:
>> only boot the system with boot node (include cpu, ram and pci root buses).
>> then after boot, could add other nodes.
>
> What exactly do you mean by "after boot"? Often, the boot process of
> userspace needs those additional cpus and ram in order to initialize
> everything (like the pci devices) properly.
Exactly. That's why I left both low and high memory on each node.
>
> 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/
Powered by blists - more mailing lists