Hello, Yinghai.

On Fri, Jun 22, 2012 at 12:23:24PM -0700, Yinghai Lu wrote:

quoted

Thanks for checking it.  I was worried because of the re-reservation
of reserved.regions after giving memory to the page allocator -
ie. memblock_reserve_reserved_regions() call.  If memblock is done at
that point, there's no reason to have that call at all.  It could be
that that's just dead code.  If so, why aren't we freeing
memory.regions?

During converting bootmem to use early_res stage, I still kept the
numa handling.
like one node by one node. So need to put the reserved.regions back.
Later found we could do that for all node at the same time.

For memory.regions, a little different, at that time I want to kill
e820 all like e820_all_mapped_ram.

Yes, we should get back region that is allocated for doubled memory.regions.
but did not trigger that doubling yet.

Also for x86, all memblock in __initdata, and will be freed later.

Thanks for the explanation.

quoted

Also, shouldn't we be clearing
memblock.cnt/max/total_size/regions so that we know for sure that it's
never used again?  What am I missing?

64bit mem_init(), after absent_page_in_range(), will not need memblock anymore.
  --- absent_page_in_range will refer for_each_mem_pfn_range.

so after that could clear that for memory.regions too.

I wish we had a single call - say, memblock_die(), or whatever - so
that there's a clear indication that memblock usage is done, but yeah
maybe another day.  Will review the patch itself.  BTW, can't you post
patches inline anymore?  Attaching is better than corrupt but is still
a bit annoying for review.

Thanks.

-- 
tejun

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>