Re: [PATCH 5/5] SRAT cleanup: make calculations and indenting level more sane

[James Cleverdon <jamesclv@us.ibm.com>]

Actually, SRAT was cooked up by the folks at Redmond or Bellevue.  If 
it's still outside of the main ACPI doc tree, well, that says a lot.


On Thursday 24 February 2005 02:02 pm, keith wrote:
> On Thu, 2005-02-24 at 12:49, James Cleverdon wrote:
> > No, I don't think we could rely on that.  Our BIOS did ascending
> > addresses, but I don't recall that being spelled out in the ACPI
> > spec.
> >
> > Of course, there's a new ACPI spec out.  Maybe it makes it a
> > requirement.  I'd take a look, but I can't afford the loss of
> > sanity caused by gazing on the dread visage of ACPI 3.0.   ;^)
>
> The SRAT exists outside of the ACPI spec.  It is something made up by
> folks in Kirkland.  I just reread the SRAT spec and I don't seen any
> mention of requirements for linear order.  Still yet we have yet to
> find a box/bios version that breaks this assumption. All I know of is
> the IBM summit boxes but maybe there is something else.
>
> Maybe AMD x86_64 booting into 32 bit have SRATs as well?
>
> Anyways maybe we could add some check to catch new hardware with less
> friendly SRAT tables.
>
> after the  node_has_online_mem(nid) check
>
> if (node_start_pfn[nid] > node_memory_chunk[j].start_pfn) {
> 	printk (KERN_WARN "You need to rework the srat.c code\n");
> 	continue;
> }
>
> Keith

-- 
James Cleverdon
IBM LTC (xSeries Linux Solutions)
{jamesclv(Unix, preferred), cleverdj(Notes)} at us dot ibm dot comm
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>