Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753371Ab3FYSir (ORCPT ); Tue, 25 Jun 2013 14:38:47 -0400 Received: from mail-ie0-f181.google.com ([209.85.223.181]:48903 "EHLO mail-ie0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752680Ab3FYSim (ORCPT ); Tue, 25 Jun 2013 14:38:42 -0400 MIME-Version: 1.0 In-Reply-To: <51C9D4ED.5070805@sgi.com> References: <1371831934-156971-1-git-send-email-nzimmer@sgi.com> <20130621165142.GA32125@kroah.com> <51C48745.9030304@zytor.com> <20130621185056.GA23473@kroah.com> <51C4C5F3.3050800@sgi.com> <51C9D4ED.5070805@sgi.com> Date: Tue, 25 Jun 2013 11:38:42 -0700 X-Google-Sender-Auth: P3vywvuWiYFoJjlSFu3An9RJPgk Message-ID: Subject: Re: [RFC 0/2] Delay initializing of large sections of memory From: Yinghai Lu To: Mike Travis Cc: Greg KH , "H. Peter Anvin" , Nathan Zimmer , Robin Holt , Rob Landley , Thomas Gleixner , Ingo Molnar , Andrew Morton , "the arch/x86 maintainers" , linux-doc@vger.kernel.org, Linux Kernel Mailing List Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1656 Lines: 39 On Tue, Jun 25, 2013 at 10:35 AM, Mike Travis wrote: > > > On 6/21/2013 5:23 PM, Yinghai Lu wrote: >> On Fri, Jun 21, 2013 at 2:30 PM, Mike Travis wrote: >>> Exactly. That's why I left both low and high memory on each node. >> >> looks like you assume every node have same ram, and before booting you >> you need to know memory layout to append the boot command line. >> >> We have patchset that moving srat table parse early. >> git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git >> for-x86-mm >> https://git.kernel.org/cgit/linux/kernel/git/yinghai/linux-yinghai.git/log/?h=for-x86-mm >> >> on top that, we could make your patch pass more simple command like >> 1/2^n of every node, and only need to pass n instead. > > The two params that I couldn't figure out how to provide except via kernel > param option was the memory block size (128M or 2G) and the physical > address space per node. The other 3 params can be automatically > setup by a script when the total system size is known. As soon as we > verify on the 32TB system and surmise what will be needed for 64TB, > then those 3 params can probably disappear. our "numa parsing early" patchset could provide "physical address space per node", also can calculate memory block size via alignment detection from numa info. with that, user only can pass "delay_init_mem" only. Thanks Yinghai -- 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/