Re: [RFC/PATCH] pfn_valid() more generic : arch independent part[0/2]

[Hiroyuki KAMEZAWA <kamezawa.hiroyu@jp.fujitsu.com>]

Hi,
Luck, Tony wrote:

>>Because pfn_valid() often returns 0 in inner loop of free_pages_bulk(),
>>I want to avoid page fault caused by using get_user() in pfn_valid().
> 
> 
> How often?  Surely this is only a problem at the edges of blocks
> of memory?  I suppose it depends on whether your discontig memory
> appears in blocks much smaller than MAXORDER.  But even there it
> should only be an issue coalescing buddies that are bigger than
> the granule size (since all of the pages in a granule on ia64 are
> guaranteed to exist, the buddy of any page must also exist).
> 
Currently, my Tiger4 shows  memory map like this.
this is a record of memmap_init() called by virtual_memmap_init().
NOTE: MAX_ORDER is 4Gbytes.

mem_map(1) from  36e    length 1fb6d  --- ZONE_DMA    (36e to 1fedb)
mem_map(2) from  1fedc  length   124  --- ZONE_DMA    (1fedc to 20000)
ZONE_DMA is 0G to 4G.
mem_map(3) from  40000  length 40000  --- ZONE_NORMAL (4G to 8G, this mem_map is aligned)
mem_map(4) from  a0000  length 20000  --- ZONE_NORMAL (10G to 12G)
mem_map(5) from  bfedc  length   124  --- ZONE_NORMAL (this is involved in mem_map(4))
ZONE_NORMAL is 4G to 12G.

node's start_pfn and end_pfn is aligned to granule size, but holes in memmap is not.
The vmemmap is aligned to # of page structs in one page.

virtual_memmap_init() is called directly from efi_memmap_walk() and
it doesn't take granule size of ia64 into account.

Hmm....
It looks what I should do is to make memmap to be aligned to ia64's granule.
thanks for your advise. I maybe considerd this problem too serious.

If vmemmap is aligned, ia64_pfn_valid() will work fine. or only 1 level table
will be needed.

Thanks.

Kame <kamezawa.hiroyu@jp.fujitsu.com>
--
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:"aart@kvack.org"> aart@kvack.org </a>