From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932316AbbJMM44 (ORCPT ); Tue, 13 Oct 2015 08:56:56 -0400 Received: from www.linutronix.de ([62.245.132.108]:49801 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932142AbbJMM4p (ORCPT ); Tue, 13 Oct 2015 08:56:45 -0400 Date: Tue, 13 Oct 2015 14:55:58 +0200 (CEST) From: Thomas Gleixner To: Jiang Liu cc: Daniel J Blueman , Denys Vlasenko , Ingo Molnar , Len Brown , x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 3/3] x86/apic: Use smaller array for __apicid_to_node[] mapping In-Reply-To: <561CCF92.1030909@linux.intel.com> Message-ID: References: <1443813145-29102-1-git-send-email-dvlasenk@redhat.com> <1443813145-29102-3-git-send-email-dvlasenk@redhat.com> <5617DEC4.5060705@linux.intel.com> <1444645261.25258.1@outlook-emeawest.office365.com> <561CCF92.1030909@linux.intel.com> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 13 Oct 2015, Jiang Liu wrote: > On 2015/10/12 18:25, Thomas Gleixner wrote: > > On Mon, 12 Oct 2015, Daniel J Blueman wrote: > >> Another approach which may be suitable without changing SRAT parsing to be > >> after the memory allocator is up, is to exploit the associativity of the > >> bottom APIC ID bits. > > > > What's the problem with moving (SRAT/ACPI/whatever) APIC parsing after > > the memory allocator is up and available? > Hi Thomas, > The work flow is as below at boot: > 1) figure out memory NUMA topology info by walking ACPI table or probing > AMD northbirdge. > 2) initialize memory allocation based on memory NUMA topology. > > And to make code simple, it also scan CPU NUMA topology in step 1, so > we could avoid walking ACPI tables twice. On the other hand, there are > several subsystems having code pattern as follow before booting APs. > up: > for_each_possible_cpu(cpu) > alloc_page_node(size, cpu_to_node(cpu)) > So it's a little hard to find a suitable hook point to delay CPU NUMA > topology scanning after memory allocator is ready. Not really. The memory allocator is available very early and long before smp_prepare_cpus(). So we should try hard to move it after that point, even if that means that we need to walk the tables twice. Alternatively, use a bootmem allocation and convert it to a radix tree when the allocator is up. Thanks, tglx