> Below is a small extension of the numa file in the vm Documenation branch
> which tries to give a brief explanation about pg_data_t and zone_t
> structs. Patch is against 2.4.19pre7 but I think it'll apply to any 2.4.x
> or 2.5.x kernel. No change of code etc etc etc. Comments, corrections and
> opinions very welcome
Nice job. Thanks for doing this.
> + node_start_paddr The starting physical addres of the node?
Yes. Note that it's an unsigned long, which doesn't work for ia32
with PAE (just as a for instance). Using a pfn (page frame number)
would be a better choice here, IMHO (see my definition of pfn below).
Same comment for zone_start_paddr.
> + node_start_mapnr This appears to be a "nice" place to put the zone
> inside + the larger mem_map. It's set during
> + free_page_init_core. Presumably there is some
> architecture + dependant way of defining nice.
Nice would be a strange term to use in this context - it's an ugly
hack ;-) It's the offset of the lmem_map array for that node within
the global mem_map array, which doesn't really exist (I'm calling
them arrays, though they're really just pointers - we use them like
arrays though). mem_map is some arbitrary constant, set to point to
PAGE_OFFSET or something similar.
> + zone_start_mapnr Address inside mem_map ?
Yes. Same comment as above ;-)
Note that there are two possible ways to define a pfn, in my mind.
One would be page_phys_addr >> PAGE_SHIFT. The other would be the
offset of the struct page for that page within the mythical mem_map
array. I prefer the former, though it probably contradicts everyone
else ;-) It's useful to have some way to pass around a 36 bit address
inside a 32 bit field.
M.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Apr 23 2002 - 22:00:23 EST