From: Linus Torvalds <torvalds@linux-foundation.org>
To: Andrea Arcangeli <aarcange@redhat.com>
Cc: Pekka Enberg <penberg@cs.helsinki.fi>,
Ingo Molnar <mingo@elte.hu>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, Marcelo Tosatti <mtosatti@redhat.com>,
Adam Litke <agl@us.ibm.com>, Avi Kivity <avi@redhat.com>,
Izik Eidus <ieidus@redhat.com>,
Hugh Dickins <hugh.dickins@tiscali.co.uk>,
Nick Piggin <npiggin@suse.de>, Rik van Riel <riel@redhat.com>,
Mel Gorman <mel@csn.ul.ie>, Dave Hansen <dave@linux.vnet.ibm.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Mike Travis <travis@sgi.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Christoph Lameter <cl@linux-foundation.org>,
Chris Wright <chrisw@sous-sol.org>,
bpicco@redhat.com,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Balbir Singh <balbir@linux.vnet.ibm.com>,
Arnd Bergmann <arnd@arndb.de>,
"Michael S. Tsirkin" <mst@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
Subject: Re: [RFD] Re: [PATCH 00 of 41] Transparent Hugepage Support #17
Date: Mon, 5 Apr 2010 18:35:43 -0700 (PDT) [thread overview]
Message-ID: <alpine.LFD.2.00.1004051833240.5870@i5.linux-foundation.org> (raw)
In-Reply-To: <alpine.LFD.2.00.1004051747030.21411@i5.linux-foundation.org>
On Mon, 5 Apr 2010, Linus Torvalds wrote:
>
> THIS PATCH IS TOTALLY UNTESTED!
Ok, it was also crap. I tried to warn you. We actually have that
"split_page()" function that does the right thing, I don't know why I
didn't realize that.
And the lock was uninitialized for the optimistic case, because I had made
that "clever optimization" to let the caller do the unlocking in the
common path, but when I did that I didn't actually make sure that the
caller had the right lock. Whee.
I'm a moron.
This is _still_ untested and probably horribly buggy, but at least it
isn't *quite* as rough as the previous patch was.
Linus
---
include/linux/gfp.h | 3 ++
mm/memory.c | 65 +++++++++++++++++++++++++++++++++++++++++++++++++++
mm/mempolicy.c | 9 +++++++
3 files changed, 77 insertions(+), 0 deletions(-)
diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index 4c6d413..2b8f42b 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -84,6 +84,7 @@ struct vm_area_struct;
#define GFP_HIGHUSER_MOVABLE (__GFP_WAIT | __GFP_IO | __GFP_FS | \
__GFP_HARDWALL | __GFP_HIGHMEM | \
__GFP_MOVABLE)
+#define GFP_USER_ORDER (GFP_HIGHUSER_MOVABLE | __GFP_ZERO | __GFP_NOWARN | __GFP_NORETRY)
#define GFP_IOFS (__GFP_IO | __GFP_FS)
#ifdef CONFIG_NUMA
@@ -306,10 +307,12 @@ alloc_pages(gfp_t gfp_mask, unsigned int order)
}
extern struct page *alloc_page_vma(gfp_t gfp_mask,
struct vm_area_struct *vma, unsigned long addr);
+extern struct page *alloc_page_user_order(struct vm_area_struct *, unsigned long, int);
#else
#define alloc_pages(gfp_mask, order) \
alloc_pages_node(numa_node_id(), gfp_mask, order)
#define alloc_page_vma(gfp_mask, vma, addr) alloc_pages(gfp_mask, 0)
+#define alloc_page_user_order(vma, addr, order) alloc_pages(GFP_USER_ORDER, order)
#endif
#define alloc_page(gfp_mask) alloc_pages(gfp_mask, 0)
diff --git a/mm/memory.c b/mm/memory.c
index 1d2ea39..4f1521e 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2742,6 +2742,66 @@ out_release:
}
/*
+ * See if we can optimistically fill eight pages at a time
+ */
+static spinlock_t *optimistic_fault(struct mm_struct *mm, struct vm_area_struct *vma,
+ unsigned long address, pte_t *page_table, pmd_t *pmd)
+{
+ int i;
+ spinlock_t *ptl;
+ struct page *bigpage;
+
+ /* Don't even bother if it's not writable */
+ if (!(vma->vm_flags & VM_WRITE))
+ return NULL;
+
+ /* Are we ok wrt the vma boundaries? */
+ if ((address & (PAGE_MASK << 3)) < vma->vm_start)
+ return NULL;
+ if ((address | ~(PAGE_MASK << 3)) > vma->vm_end)
+ return NULL;
+
+ /*
+ * Round to a nice even 8-byte page boundary, and
+ * optimistically (with no locking), check whether
+ * it's all empty. Skip if we have it partly filled
+ * in.
+ *
+ * 8 page table entries tends to be about a cacheline.
+ */
+ page_table -= (address >> PAGE_SHIFT) & 7;
+ for (i = 0; i < 8; i++)
+ if (!pte_none(page_table[i]))
+ return NULL;
+
+ /* Allocate the eight pages in one go, no warning or retrying */
+ bigpage = alloc_page_user_order(vma, addr, 3);
+ if (!bigpage)
+ return NULL;
+
+ split_page(bigpage, 3);
+
+ ptl = pte_lockptr(mm, pmd);
+ spin_lock(ptl);
+
+ for (i = 0; i < 8; i++) {
+ struct page *page = bigpage + i;
+
+ if (pte_none(page_table[i])) {
+ pte_t pte = mk_pte(page, vma->vm_page_prot);
+ pte = pte_mkwrite(pte_mkdirty(pte));
+ set_pte_at(mm, address, page_table+i, pte);
+ } else {
+ __free_page(page);
+ }
+ }
+
+ /* The caller will unlock */
+ return ptl;
+}
+
+
+/*
* We enter with non-exclusive mmap_sem (to exclude vma changes,
* but allow concurrent faults), and pte mapped but not yet locked.
* We return with mmap_sem still held, but pte unmapped and unlocked.
@@ -2754,6 +2814,10 @@ static int do_anonymous_page(struct mm_struct *mm, struct vm_area_struct *vma,
spinlock_t *ptl;
pte_t entry;
+ ptl = optimistic_fault(mm, vma, address, page_table, pmd);
+ if (ptl)
+ goto update;
+
if (!(flags & FAULT_FLAG_WRITE)) {
entry = pte_mkspecial(pfn_pte(my_zero_pfn(address),
vma->vm_page_prot));
@@ -2790,6 +2854,7 @@ static int do_anonymous_page(struct mm_struct *mm, struct vm_area_struct *vma,
setpte:
set_pte_at(mm, address, page_table, entry);
+update:
/* No need to invalidate - it was non-present before */
update_mmu_cache(vma, address, page_table);
unlock:
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index 08f40a2..55a92bd 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -1707,6 +1707,15 @@ alloc_page_vma(gfp_t gfp, struct vm_area_struct *vma, unsigned long addr)
return __alloc_pages_nodemask(gfp, 0, zl, policy_nodemask(gfp, pol));
}
+struct page *
+alloc_page_user_order(struct vm_area_struct *vma, unsigned long addr, int order)
+{
+ struct zonelist *zl = policy_zonelist(gfp, pol);
+ struct mempolicy *pol = get_vma_policy(current, vma, addr);
+
+ return __alloc_pages_nodemask(GFP_USER_ORDER, order, zl, pol);
+}
+
/**
* alloc_pages_current - Allocate pages.
*
--
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>
next prev parent reply other threads:[~2010-04-06 1:40 UTC|newest]
Thread overview: 205+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-02 0:41 Andrea Arcangeli
2010-04-02 0:41 ` [PATCH 01 of 41] define MADV_HUGEPAGE Andrea Arcangeli
2010-04-02 0:41 ` [PATCH 02 of 41] compound_lock Andrea Arcangeli
2010-04-02 0:41 ` [PATCH 03 of 41] alter compound get_page/put_page Andrea Arcangeli
2010-04-02 0:41 ` [PATCH 04 of 41] update futex compound knowledge Andrea Arcangeli
2010-04-02 0:41 ` [PATCH 05 of 41] fix bad_page to show the real reason the page is bad Andrea Arcangeli
2010-04-02 0:41 ` [PATCH 06 of 41] clear compound mapping Andrea Arcangeli
2010-04-02 0:41 ` [PATCH 07 of 41] add native_set_pmd_at Andrea Arcangeli
2010-04-02 0:41 ` [PATCH 08 of 41] add pmd paravirt ops Andrea Arcangeli
2010-04-02 0:41 ` [PATCH 09 of 41] no paravirt version of pmd ops Andrea Arcangeli
2010-04-02 0:41 ` [PATCH 10 of 41] export maybe_mkwrite Andrea Arcangeli
2010-04-02 0:41 ` [PATCH 11 of 41] comment reminder in destroy_compound_page Andrea Arcangeli
2010-04-02 0:41 ` [PATCH 12 of 41] config_transparent_hugepage Andrea Arcangeli
2010-04-02 0:41 ` [PATCH 13 of 41] special pmd_trans_* functions Andrea Arcangeli
2010-04-02 0:41 ` [PATCH 14 of 41] add pmd mangling generic functions Andrea Arcangeli
2010-04-02 0:41 ` [PATCH 15 of 41] add pmd mangling functions to x86 Andrea Arcangeli
2010-04-02 0:41 ` [PATCH 16 of 41] bail out gup_fast on splitting pmd Andrea Arcangeli
2010-04-02 0:41 ` [PATCH 17 of 41] pte alloc trans splitting Andrea Arcangeli
2010-04-02 0:41 ` [PATCH 18 of 41] add pmd mmu_notifier helpers Andrea Arcangeli
2010-04-02 0:41 ` [PATCH 19 of 41] clear page compound Andrea Arcangeli
2010-04-02 0:41 ` [PATCH 20 of 41] add pmd_huge_pte to mm_struct Andrea Arcangeli
2010-04-02 0:41 ` [PATCH 21 of 41] split_huge_page_mm/vma Andrea Arcangeli
2010-04-02 0:41 ` [PATCH 22 of 41] split_huge_page paging Andrea Arcangeli
2010-04-02 0:41 ` [PATCH 23 of 41] clear_copy_huge_page Andrea Arcangeli
2010-04-02 0:41 ` [PATCH 24 of 41] kvm mmu transparent hugepage support Andrea Arcangeli
2010-04-02 0:41 ` [PATCH 25 of 41] _GFP_NO_KSWAPD Andrea Arcangeli
2010-04-02 0:41 ` [PATCH 26 of 41] don't alloc harder for gfp nomemalloc even if nowait Andrea Arcangeli
2010-04-02 0:41 ` [PATCH 27 of 41] transparent hugepage core Andrea Arcangeli
2010-04-02 0:41 ` [PATCH 28 of 41] verify pmd_trans_huge isn't leaking Andrea Arcangeli
2010-04-02 0:41 ` [PATCH 29 of 41] madvise(MADV_HUGEPAGE) Andrea Arcangeli
2010-04-02 0:41 ` [PATCH 30 of 41] pmd_trans_huge migrate bugcheck Andrea Arcangeli
2010-04-02 0:41 ` [PATCH 31 of 41] memcg compound Andrea Arcangeli
2010-04-02 0:41 ` [PATCH 32 of 41] memcg huge memory Andrea Arcangeli
2010-04-02 0:42 ` [PATCH 33 of 41] transparent hugepage vmstat Andrea Arcangeli
2010-04-02 0:42 ` [PATCH 34 of 41] khugepaged Andrea Arcangeli
2010-04-02 0:42 ` [PATCH 35 of 41] skip transhuge pages in ksm for now Andrea Arcangeli
2010-04-02 0:42 ` [PATCH 36 of 41] remove PG_buddy Andrea Arcangeli
2010-04-02 0:42 ` [PATCH 37 of 41] add x86 32bit support Andrea Arcangeli
2010-04-02 0:42 ` [PATCH 38 of 41] mincore transparent hugepage support Andrea Arcangeli
2010-04-02 0:42 ` [PATCH 39 of 41] add pmd_modify Andrea Arcangeli
2010-04-02 0:42 ` [PATCH 40 of 41] mprotect: pass vma down to page table walkers Andrea Arcangeli
2010-04-02 0:42 ` [PATCH 41 of 41] mprotect: transparent huge page support Andrea Arcangeli
2010-04-05 19:09 ` [PATCH 00 of 41] Transparent Hugepage Support #17 Andrew Morton
2010-04-05 19:36 ` Ingo Molnar
2010-04-05 20:26 ` Pekka Enberg
2010-04-05 20:32 ` Linus Torvalds
2010-04-05 20:46 ` Pekka Enberg
2010-04-05 20:58 ` Linus Torvalds
2010-04-05 21:54 ` Ingo Molnar
2010-04-05 23:21 ` Andrea Arcangeli
2010-04-06 0:26 ` Linus Torvalds
2010-04-06 1:08 ` [RFD] " Linus Torvalds
2010-04-06 1:26 ` Andrea Arcangeli
2010-04-06 1:35 ` Linus Torvalds [this message]
2010-04-06 1:13 ` Andrea Arcangeli
2010-04-06 1:38 ` Linus Torvalds
2010-04-06 2:23 ` Linus Torvalds
2010-04-06 5:25 ` Nick Piggin
2010-04-06 9:08 ` Ingo Molnar
2010-04-06 9:13 ` Ingo Molnar
2010-04-10 18:47 ` Andrea Arcangeli
2010-04-10 19:02 ` Ingo Molnar
2010-04-10 19:22 ` Avi Kivity
2010-04-10 19:47 ` Ingo Molnar
2010-04-10 20:00 ` Andrea Arcangeli
2010-04-10 20:10 ` Andrea Arcangeli
2010-04-10 20:21 ` Jason Garrett-Glaser
2010-04-10 20:24 ` Avi Kivity
2010-04-10 20:42 ` Avi Kivity
2010-04-10 20:47 ` Andrea Arcangeli
2010-04-10 21:00 ` Avi Kivity
2010-04-10 21:47 ` Andrea Arcangeli
2010-04-11 1:05 ` Andrea Arcangeli
2010-04-11 11:24 ` Ingo Molnar
2010-04-11 11:33 ` Avi Kivity
2010-04-11 12:11 ` Ingo Molnar
2010-04-25 19:27 ` Andrea Arcangeli
2010-04-26 18:01 ` Andrea Arcangeli
2010-04-30 9:55 ` Ingo Molnar
2010-04-30 15:19 ` Andrea Arcangeli
2010-05-02 12:17 ` Ingo Molnar
2010-04-10 20:49 ` Jason Garrett-Glaser
2010-04-10 20:53 ` Avi Kivity
2010-04-10 20:58 ` Jason Garrett-Glaser
2010-04-11 9:29 ` Avi Kivity
2010-04-11 9:37 ` Jason Garrett-Glaser
2010-04-11 9:40 ` Avi Kivity
2010-04-11 10:22 ` Jason Garrett-Glaser
2010-04-11 11:00 ` Ingo Molnar
2010-04-11 11:19 ` Avi Kivity
2010-04-11 11:30 ` Jason Garrett-Glaser
2010-04-11 11:52 ` hugepages will matter more in the future Ingo Molnar
2010-04-11 12:01 ` Avi Kivity
2010-04-11 12:35 ` Ingo Molnar
2010-04-11 15:22 ` Linus Torvalds
2010-04-11 15:43 ` Avi Kivity
2010-04-11 15:52 ` Linus Torvalds
2010-04-11 16:04 ` Avi Kivity
2010-04-12 7:45 ` Ingo Molnar
2010-04-12 8:14 ` Nick Piggin
2010-04-12 8:22 ` Ingo Molnar
2010-04-12 8:34 ` Nick Piggin
2010-04-12 8:47 ` Avi Kivity
2010-04-12 8:45 ` Andrea Arcangeli
2010-04-11 19:35 ` Andrea Arcangeli
2010-04-12 16:20 ` Rik van Riel
2010-04-12 16:40 ` Linus Torvalds
2010-04-12 16:56 ` Linus Torvalds
2010-04-12 17:06 ` Randy Dunlap
2010-04-12 17:36 ` Andrea Arcangeli
2010-04-12 17:46 ` Rik van Riel
2010-04-11 19:40 ` Andrea Arcangeli
2010-04-12 15:41 ` Linus Torvalds
2010-04-12 11:22 ` Arjan van de Ven
2010-04-12 11:29 ` Avi Kivity
2010-04-17 15:12 ` Arjan van de Ven
2010-04-17 18:18 ` Avi Kivity
2010-04-17 19:05 ` Arjan van de Ven
2010-04-17 19:05 ` Avi Kivity
2010-04-17 19:18 ` Arjan van de Ven
2010-04-17 19:20 ` Avi Kivity
2010-04-12 13:30 ` Andrea Arcangeli
2010-04-12 13:33 ` Avi Kivity
2010-04-12 13:39 ` Andrea Arcangeli
2010-04-12 13:53 ` Avi Kivity
2010-04-13 11:38 ` Ingo Molnar
2010-04-13 13:17 ` Andrea Arcangeli
2010-04-11 10:46 ` [PATCH 00 of 41] Transparent Hugepage Support #17 Ingo Molnar
2010-04-11 10:49 ` Ingo Molnar
2010-04-11 11:30 ` Avi Kivity
2010-04-11 12:08 ` Ingo Molnar
2010-04-11 12:24 ` Avi Kivity
2010-04-11 12:46 ` Ingo Molnar
2010-04-12 6:09 ` Nick Piggin
2010-04-12 6:18 ` Pekka Enberg
2010-04-12 6:48 ` Nick Piggin
2010-04-12 14:29 ` Christoph Lameter
2010-04-12 16:06 ` Nick Piggin
2010-04-12 6:36 ` Avi Kivity
2010-04-12 6:55 ` Ingo Molnar
2010-04-12 7:15 ` Nick Piggin
2010-04-12 7:45 ` Avi Kivity
2010-04-12 8:28 ` Nick Piggin
2010-04-12 9:01 ` Andrea Arcangeli
2010-04-12 9:03 ` Avi Kivity
2010-04-12 9:26 ` Nick Piggin
2010-04-12 9:39 ` Andrea Arcangeli
2010-04-12 10:02 ` Avi Kivity
2010-04-12 10:08 ` Andrea Arcangeli
2010-04-12 10:10 ` Avi Kivity
2010-04-12 10:23 ` Andrea Arcangeli
2010-04-12 10:37 ` Nick Piggin
2010-04-12 10:59 ` Avi Kivity
2010-04-12 12:23 ` Avi Kivity
2010-04-12 13:25 ` Andrea Arcangeli
2010-04-13 0:38 ` Andrew Morton
2010-04-13 6:18 ` Neil Brown
2010-04-13 13:31 ` Andrea Arcangeli
2010-04-13 13:40 ` Mel Gorman
2010-04-13 13:44 ` Andrea Arcangeli
2010-04-13 13:55 ` Mel Gorman
2010-04-13 14:03 ` Andrea Arcangeli
2010-04-12 7:51 ` Ingo Molnar
2010-04-12 7:18 ` Andrea Arcangeli
2010-04-12 6:49 ` Ingo Molnar
2010-04-12 7:35 ` Andrea Arcangeli
2010-04-12 7:08 ` Andrea Arcangeli
2010-04-12 7:21 ` Nick Piggin
2010-04-12 7:50 ` Avi Kivity
2010-04-12 8:07 ` Ingo Molnar
2010-04-12 8:21 ` Andrea Arcangeli
2010-04-12 10:27 ` Mel Gorman
2010-04-12 8:18 ` Andrea Arcangeli
2010-04-12 8:06 ` Andrea Arcangeli
2010-04-12 10:44 ` Mel Gorman
2010-04-12 11:12 ` Avi Kivity
2010-04-12 13:17 ` Andrea Arcangeli
2010-04-12 14:24 ` Christoph Lameter
2010-04-12 14:49 ` Avi Kivity
2010-04-06 9:55 ` Avi Kivity
2010-04-06 9:57 ` Avi Kivity
2010-04-06 11:55 ` Avi Kivity
2010-04-06 13:10 ` Nick Piggin
2010-04-06 13:22 ` Avi Kivity
2010-04-06 13:45 ` Nick Piggin
2010-04-06 13:57 ` Avi Kivity
2010-04-06 16:50 ` Andrea Arcangeli
2010-04-06 17:31 ` Avi Kivity
2010-04-06 18:00 ` Christoph Lameter
2010-04-06 18:04 ` Avi Kivity
2010-04-06 18:47 ` Avi Kivity
2010-04-06 14:44 ` Rik van Riel
2010-04-06 16:43 ` Andrea Arcangeli
2010-04-06 9:30 ` Mel Gorman
2010-04-06 10:32 ` Theodore Tso
2010-04-06 11:16 ` Mel Gorman
2010-04-06 13:13 ` Theodore Tso
2010-04-06 14:55 ` Mel Gorman
2010-04-06 16:46 ` Andrea Arcangeli
2010-04-05 21:01 ` Chris Mason
2010-04-05 21:18 ` Avi Kivity
2010-04-05 21:33 ` Linus Torvalds
2010-04-05 22:33 ` Chris Mason
2010-04-06 8:30 ` Mel Gorman
2010-04-06 11:35 ` Chris Mason
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LFD.2.00.1004051833240.5870@i5.linux-foundation.org \
--to=torvalds@linux-foundation.org \
--cc=aarcange@redhat.com \
--cc=agl@us.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=avi@redhat.com \
--cc=balbir@linux.vnet.ibm.com \
--cc=benh@kernel.crashing.org \
--cc=bpicco@redhat.com \
--cc=chrisw@sous-sol.org \
--cc=cl@linux-foundation.org \
--cc=dave@linux.vnet.ibm.com \
--cc=hannes@cmpxchg.org \
--cc=hugh.dickins@tiscali.co.uk \
--cc=ieidus@redhat.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
--cc=mingo@elte.hu \
--cc=mst@redhat.com \
--cc=mtosatti@redhat.com \
--cc=nishimura@mxp.nes.nec.co.jp \
--cc=npiggin@suse.de \
--cc=penberg@cs.helsinki.fi \
--cc=peterz@infradead.org \
--cc=riel@redhat.com \
--cc=travis@sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox