Transparent Hugepage support #2]

PATCH Andrew Morton 2 participants 2 messages Dec 22, 2009 3 messages not in the archive Memory management

lore

Share & tools

lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

Andrew Morton

author maintainer

2009-12-22 23:35 UTC #3 lore raw

Quoted 12 lines · On Sat, 19 Dec 2009 17:03:00 +0100 Andrea Arcangeli <[email protected]> wrote:

Subject: clear_huge_page fix
From: Andrea Arcangeli <[email protected]>
sz is in bytes, MAX_ORDER_NR_PAGES is in pages.
Signed-off-by Andrea Arcangeli <[email protected]>
---

mm/hugetlb.c static void clear_huge_page(struct page · line 407

Quoted 8 lines

mm/hugetlb.c +1 -1

@@ -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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Andrea Arcangeli

2009-12-22 23:50 UTC #4 lore raw

Hi Andrew,

Quoted 17 lines · Andrew Morton

: 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);
: }
: }

Quoted 5 lines

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.