On Fri, Feb 08, 2008 at 02:46:25PM -0800, Luck, Tony wrote:
> Petr Tesarik (3):
> [IA64] Rename TIF_PERFMON_WORK back to TIF_NOTIFY_RESUME
> [IA64] Synchronize kernel RSE to user-space and back
> [IA64] Synchronize RBS on PTRACE_ATTACH
This is still not killing the now unessecary
> Not that I can think of. The early_cpu_possible_map will be a superset
> of the cpu_possible_map.
It might be a bigger superset than we'd like ... I'm not sure if there
are any hard rules about how SRAT tables are populated. W.r.t. memory
the entries tend to be broad: "If there is any memory i
On Fri, Feb 08, 2008 at 03:10:25PM -0800, Luck, Tony wrote:
> > This patch could be using the cpu_possible_map instead of our own.
> > I was reluctant to do that, but there is nothing that prevents it.
> > Does anybody have an opinion?
>
> I hate to see duplication ... your new "early_cpu_possible
> This patch could be using the cpu_possible_map instead of our own.
> I was reluctant to do that, but there is nothing that prevents it.
> Does anybody have an opinion?
I hate to see duplication ... your new "early_cpu_possible_map" should
just end up with the same contents as "cpu_possible_map"
The attached patch significantly shrinks boot memory allocation on ia64.
It does this by not allocating per_cpu areas for cpus that can never
exist.
In the case where acpi does not have any numa node description of
the cpus, I defaulted to assigning the first 4 to node 0. For the
!CONFIG_ACPI I
Hi Linus,
please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6.git release
This will update the files shown below.
Thanks!
-Tony
arch/ia64/kernel/entry.S |5 +-
arch/ia64/kernel/mca.c | 55
arch/ia64/kernel/perfmon.c
