Re: [PATCH 4/6] Have x86_64 use add_active_range() and free_area_init_nodes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Mel Gorman wrote:
On Thu, 31 Aug 2006, Mika Penttilä 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 = (end_pfn - e820_hole_size(0, end_pfn)) * PAGE_SIZE;
+ allowed = (end_pfn - absent_pages_in_range(0, end_pfn)) * PAGE_SIZE;
       allowed = (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 now. */
-       if (e820_hole_size(s_pfn, e_pfn) != e_pfn - s_pfn) {
+       if (absent_pages_in_range(s_pfn, e_pfn) != e_pfn - s_pfn) {
printk(KERN_ERR "SRAT: Hotplug area has existing memory\n");
               return -1;
       }

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)

The information used by absent_pages_in_range() should match what was
available to e820_hole_size().


But it doesn't : all active ranges are removed before parsing srat. I think 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 should be using the same information that was available in e820. What am I missing?

Ok, right, missed the e820_register_active_ranges() in acpi_numa_memory_affinity_init() before reserve_hotadd stuff. So logically it should be working mod bugs.

Argh, just looked through the reserve hotadd code and hotadd_enough_memory() looks still broken. And why are we doing reserve_bootmem_node(), the regions aren't present RAM anyways?

--Mika

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux