Re: clean up mem_map usage ... part 1

["Martin J. Bligh" <Martin.Bligh@us.ibm.com>]

>> 2. mapnr. This is the index into the mem_map array. For contigmem,
>> thats equiv to a pfn, and more or less made some sense.
>> For discontigmem that's a nasty hack. We don't have a mem_map array,
>> we have an lmem_map array per pg_data_t (aka node or memory chunk).
>> But we somehow decided to define mem_map = PAGE_OFFSET, then
>> retend the whole of the virtual address space is some kind of klunky
>> mem_map array with holes in. So node_start_mapnr = lmem_map - mem_map ....
>> except that's really arith on struct pages, so it's the distance / sizeof(struct page).
>> So we have to align lmem_map allocations on a boundary of size sizeof(struct page),
>> except that's really a boundary from PAGE_OFFSET, not absolute vaddr.
>> Gack. Look at free_area_init_core. It's unpleasant ;-)
> 
> I wish you hadn't told me all that.

;-) 

But when I send you the patch to rip it all out, you'll be happy now ;-)

M.


--
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/