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

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

[Luck, Tony]

>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).

Do you have some data to show that this is a problem.

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

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

[Hiroyuki KAMEZAWA]

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>

Re: align vmemmap to ia64's granule

[Hiroyuki KAMEZAWA]

Hi, Tony

This patch make vmemmap to be aligned with ia64's granule size, against 2.6.9-rc3.
Please apply this, if vmemmap is expected to be aligned with the granule size.

Kame <kamezawa.hiroyu@jp.fujitsu.com>

Hiroyuki KAMEZAWA wrote:
> 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).

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


---

  test-kernel-kamezawa/arch/ia64/mm/init.c |    2 ++
  1 files changed, 2 insertions(+)

diff -puN arch/ia64/mm/init.c~vmemmap_align_granule arch/ia64/mm/init.c
--- test-kernel/arch/ia64/mm/init.c~vmemmap_align_granule	2004-10-07 15:24:08.322733968 +0900
+++ test-kernel-kamezawa/arch/ia64/mm/init.c	2004-10-07 15:30:58.623358792 +0900
@@ -411,6 +411,8 @@ virtual_memmap_init (u64 start, u64 end,

  	args = (struct memmap_init_callback_data *) arg;

+	start = GRANULEROUNDDOWN(start);
+	end  = GRANULEROUNDUP(end);
  	map_start = vmem_map + (__pa(start) >> PAGE_SHIFT);
  	map_end   = vmem_map + (__pa(end) >> PAGE_SHIFT);


_


-- 
--the clue is these footmarks leading to the door.--
KAMEZAWA Hiroyuki <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>

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

[Martin J. Bligh]

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

The normal way to fix the above is just to have a bitmap array to test - 
in your case a 1GB granularity would be sufficicent. That takes < 1 word
to implement for the example above ;-)

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

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

[Hiroyuki KAMEZAWA]

Martin J. Bligh wrote:
> The normal way to fix the above is just to have a bitmap array to test - 
> in your case a 1GB granularity would be sufficicent. That takes < 1 word
> to implement for the example above ;-)
> 
> M.
> 

Although I don't like a page fault, I now understand it doesn't often happen.
I'd like to use current implementation.

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>