Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932204AbWHaRBf (ORCPT ); Thu, 31 Aug 2006 13:01:35 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932385AbWHaRBf (ORCPT ); Thu, 31 Aug 2006 13:01:35 -0400 Received: from calculon.skynet.ie ([193.1.99.88]:35233 "EHLO calculon.skynet.ie") by vger.kernel.org with ESMTP id S932204AbWHaRBe (ORCPT ); Thu, 31 Aug 2006 13:01:34 -0400 Date: Thu, 31 Aug 2006 18:01:32 +0100 (IST) From: Mel Gorman X-X-Sender: mel@skynet.skynet.ie To: =?ISO-8859-15?Q?Mika_Penttil=E4?= Cc: Keith Mannthey , akpm@osdl.org, tony.luck@intel.com, Linux Memory Management List , ak@suse.de, bob.picco@hp.com, Linux Kernel Mailing List Subject: Re: [PATCH 4/6] Have x86_64 use add_active_range() and free_area_init_nodes In-Reply-To: <44F70D74.30807@kolumbus.fi> Message-ID: References: <20060821134518.22179.46355.sendpatchset@skynet.skynet.ie> <20060821134638.22179.44471.sendpatchset@skynet.skynet.ie> <20060831154903.GA7011@skynet.ie> <44F70D74.30807@kolumbus.fi> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="29444707-2029305836-1157043692=:13392" Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3202 Lines: 80 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --29444707-2029305836-1157043692=:13392 Content-Type: TEXT/PLAIN; charset=iso-8859-15; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Thu, 31 Aug 2006, Mika Penttil=E4 wrote: > >>>> static __init inline int srat_disabled(void) >>>> @@ -166,7 +167,7 @@ static int hotadd_enough_memory(struct b >>>> >>>> if (mem < 0) >>>> return 0; >>>> - allowed =3D (end_pfn - e820_hole_size(0, end_pfn)) * PAGE_SIZE= ; >>>> + allowed =3D (end_pfn - absent_pages_in_range(0, end_pfn)) *=20 >>>> PAGE_SIZE; >>>> allowed =3D (allowed / 100) * hotadd_percent; >>>> if (allocated + mem > allowed) { >>>> unsigned long range; >>>> @@ -238,7 +239,7 @@ static int reserve_hotadd(int node, unsi >>>> } >>>> >>>> /* This check might be a bit too strict, but I'm keeping it for= =20 >>>> now. */ >>>> - if (e820_hole_size(s_pfn, e_pfn) !=3D e_pfn - s_pfn) { >>>> + if (absent_pages_in_range(s_pfn, e_pfn) !=3D e_pfn - s_pfn) { >>>> printk(KERN_ERR "SRAT: Hotplug area has existing=20 >>>> memory\n"); >>>> return -1; >>>> } >>>>=20 >>> We really do want to to compare against the e820 map at it contains >>> the memory that is really present (this info was blown away before >>> acpi_numa)=20 >>=20 >> The information used by absent_pages_in_range() should match what was >> available to e820_hole_size(). >> >>=20 > But it doesn't : all active ranges are removed before parsing srat. I thi= nk=20 > we really need to check against e820 here. > What I see happening is this; 1. setup_arch calls e820_register_active_regions(0, 0, -1UL) so that all regions are registered as if they were on node 0 so e820_end_of_ram() gets the right value 2. remove_all_active_regions() is called to clear what was registered so that rediscovery with NUMA awareness happens 3. acpi_numa_init() is called. It parses the table and a little later calls acpi_numa_memory_affinity_init() for each range in the table so now we're into x86_64 code 4. acpi_numa_memory_affinity_init() basically deals an address range. Assuming the SRAT table is not broken, it calls e820_register_active_ranges() for that range. At this point, for the range of addresses, the active ranges are now registered 5. reserve_hotadd is called if the range is hotpluggable. It will fail if it finds that memory already exists there So, when absent_pages_in_range() is being called by reserve_hotadd(), it=20 should be using the same information that was available in e820. What am I= =20 missing? --=20 Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab --29444707-2029305836-1157043692=:13392-- - 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/