[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTik7tcZo8ka80y=FD-_UxwvB6-R8iRHRq+rkOSo+@mail.gmail.com>
Date: Thu, 6 Jan 2011 11:57:43 -0800
From: Tony Luck <tony.luck@...el.com>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
Thomas Gleixner <tglx@...utronix.de>,
Andrew Morton <akpm@...ux-foundation.org>,
Wu Fengguang <fengguang.wu@...el.com>,
Bjorn Helgaas <bjorn.helgaas@...com>,
Yinghai Lu <yinghai@...nel.org>
Subject: Re: [GIT PULL] x86/apic changes for v2.6.38
On Thu, Jan 6, 2011 at 11:22 AM, H. Peter Anvin <hpa@...or.com> wrote:
> I don't know if this is applicable on IA64.
I think that ia64 might need something like this too. If I understand the
change correctly, it makes sure that we read all entries for cpus from the
SRAT table, so that we can figure out the topology for any cpus that we
decide to use (which may be at arbitrary positions in the SRAT table
as there is no guarantee that SRAT entries are in the same order as
MADT entries ... we might try to boot the first four cpus we find in
MADT, but those might be the last four entries in SRAT.)
It looks like this could be more simply achieved in an architecture
neutral way by just passing "0" as the last argument to
acpi_table_parse_srat() ... which will look at every entry
in SRAT (this is not exactly the same ... but it seems unlikely
that SRAT will have more than 32768 processor entries ... which
you are apparently willing to allow for with the MAX_LOCAL_APIC
value.)
-Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists