Re: [aarcange@redhat.com: [PATCH 00 of 28] Transparent Hugepage support #2]

Re: [aarcange@redhat.com: [PATCH 00 of 28] Transparent Hugepage support #2]

[Andrew Morton]

On Sat, 19 Dec 2009 17:03:00 +0100
Andrea Arcangeli <aarcange@redhat.com> wrote:

> Subject: clear_huge_page fix
> From: Andrea Arcangeli <aarcange@redhat.com>
> 
> sz is in bytes, MAX_ORDER_NR_PAGES is in pages.
> 
> Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
> ---
> 
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -401,7 +401,7 @@ static void clear_huge_page(struct page 
>  {
>  	int i;
>  
> -	if (unlikely(sz > MAX_ORDER_NR_PAGES)) {
> +	if (unlikely(sz/PAGE_SIZE > MAX_ORDER_NR_PAGES)) {
>  		clear_gigantic_page(page, addr, sz);
>  		return;
>  	}

: static void clear_huge_page(struct page *page,
: 			unsigned long addr, unsigned long sz)
: {
: 	int i;
: 
: 	if (unlikely(sz > MAX_ORDER_NR_PAGES)) {
: 		clear_gigantic_page(page, addr, sz);
: 		return;
: 	}
: 
: 	might_sleep();
: 	for (i = 0; i < sz/PAGE_SIZE; i++) {
: 		cond_resched();
: 		clear_user_highpage(page + i, addr + i * PAGE_SIZE);
: 	}
: }

umph.  So we've basically never executed the clear_user_highpage() loop.

Is there any point in retaining it?  Why not just call
clear_gigantic_page() all the time, as we've been doing?  All it does
it to avoid a call to mem_map_next() per clear_page().

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

Re: [aarcange@redhat.com: [PATCH 00 of 28] Transparent Hugepage support #2]

[Andrea Arcangeli]

Hi Andrew,

On Tue, Dec 22, 2009 at 03:35:04PM -0800, Andrew Morton wrote:
> : static void clear_huge_page(struct page *page,
> : 			unsigned long addr, unsigned long sz)
> : {
> : 	int i;
> : 
> : 	if (unlikely(sz > MAX_ORDER_NR_PAGES)) {
> : 		clear_gigantic_page(page, addr, sz);
> : 		return;
> : 	}
> : 
> : 	might_sleep();
> : 	for (i = 0; i < sz/PAGE_SIZE; i++) {
> : 		cond_resched();
> : 		clear_user_highpage(page + i, addr + i * PAGE_SIZE);
> : 	}
> : }
> 
> umph.  So we've basically never executed the clear_user_highpage() loop.
> 
> Is there any point in retaining it?  Why not just call
> clear_gigantic_page() all the time, as we've been doing?  All it does
> it to avoid a call to mem_map_next() per clear_page().

My understanding is that not calling gigantic_page is faster by not
having to lookup zone changes, because compound pages created by the
buddy allocator are guaranteed to stay in the same zone or the buddy
couldn't return them. So we can just do page + i, if the compound
order is <= MAX_ORDER_NR_PAGES. It's probably lost in the noise by the
CPU waste of a 2M copy. I guess it's worth to retain given somebody
already bothered to optimize for it.

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