But this kernel had two symbols(node_online_map, node_data). Can we get the node_mem_map of each node by using these symbols? Kernel gets the pglist_data of online nodes in next_online_pgdat() by the following method. 1. get the online NODE-IDs from "node_online_map". 2. get "node_data[NODE_ID]" as the pglist_data of online nodes. Thanks Ken'ichi Ohmichi
To avoid any duplication of efforts, I'm starting work on getting
the various "kmem" command options working again for RHEL5-alpha
x86_64 kernels, into which CONFIG_SPARSEMEM was recently introduced,
and CONFIG_NUMA is also configured. So that particular kernel
uses
node_online_map and node_data. There are going to be some
variances
among the different architectures in this area, but we have to
start
somewhere. Expect fairly frequent version updates so that
we can
all be on the same page...
Note that the first thing I ran into was a problem with the SPARSEMEM
support patch that I accepted into 4.0-2.22 -- which requires this
fix:
--- memory.c 2006-08-22 14:27:51.000000000 -0400
+++ ../next/memory.c 2006-08-24 14:51:25.000000000
-0400
@@ -11374,13 +11374,16 @@ ulong
pfn_to_map(ulong pfn)
{
ulong section, page_offset;
+ ulong section_nr;
- section = pfn_to_section_nr(pfn);
+ section_nr = pfn_to_section_nr(pfn);
+ if (!(section = valid_section_nr(section_nr)))
+
return 0;
if (section_has_mem_map(section))
{
-
page_offset = pfn - section_nr_to_pfn(section);
+
page_offset = pfn - section_nr_to_pfn(section_nr);
return (section_mem_map_addr(section) +
-
(page_offset * PAGESIZE()));
+
(page_offset * SIZE(page)));
}
return 0;
This SPARSEMEM-only primitive could never have worked
since it was passing a section number into a function
expecting a section address (and even it did work, the
page address calculation was incorrect). So it always
returned 0, and therefore all of its consumers fail.
Dave
-- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
