From: "Chen, Kenneth W" <kenneth.w.chen@intel.com>
To: 'Christoph Lameter' <christoph@schroedinger.engr.sgi.com>,
'David Gibson' <david@gibson.dropbear.id.au>,
Hugh Dickins <hugh@veritas.com>,
bill.irwin@oracle.com, Andrew Morton <akpm@osdl.org>,
Adam Litke <agl@us.ibm.com>
Cc: linux-mm@kvack.org
Subject: [RFC] reduce hugetlb_instantiation_mutex usage
Date: Thu, 26 Oct 2006 15:17:20 -0700 [thread overview]
Message-ID: <000101c6f94c$8138c590$ff0da8c0@amr.corp.intel.com> (raw)
First rev of patch to allow hugetlb page fault to scale.
hugetlb_instantiation_mutex was introduced to prevent spurious allocation
failure in a corner case: two threads race to instantiate same page with
only one free page left in the global pool. However, this global
serialization hurts fault performance badly as noted by Christoph Lameter.
This patch attempt to cut back the use of mutex only when free page resource
is limited, thus allow fault to scale in most common cases.
Signed-off-by: Ken Chen <kenneth.w.chen@intel.com>
--- ./mm/hugetlb.c.orig 2006-10-26 10:26:43.000000000 -0700
+++ ./mm/hugetlb.c 2006-10-26 13:18:03.000000000 -0700
@@ -542,6 +542,8 @@ int hugetlb_fault(struct mm_struct *mm,
pte_t entry;
int ret;
static DEFINE_MUTEX(hugetlb_instantiation_mutex);
+ static atomic_t token = ATOMIC_INIT(0);
+ int use_mutex = 0;
ptep = huge_pte_alloc(mm, address);
if (!ptep)
@@ -552,12 +554,15 @@ int hugetlb_fault(struct mm_struct *mm,
* get spurious allocation failures if two CPUs race to instantiate
* the same page in the page cache.
*/
- mutex_lock(&hugetlb_instantiation_mutex);
+ if (atomic_inc_return(&token) >= free_huge_pages) {
+ mutex_lock(&hugetlb_instantiation_mutex);
+ use_mutex = 1;
+ }
+
entry = *ptep;
if (pte_none(entry)) {
ret = hugetlb_no_page(mm, vma, address, ptep, write_access);
- mutex_unlock(&hugetlb_instantiation_mutex);
- return ret;
+ goto out;
}
ret = VM_FAULT_MINOR;
@@ -568,7 +573,11 @@ int hugetlb_fault(struct mm_struct *mm,
if (write_access && !pte_write(entry))
ret = hugetlb_cow(mm, vma, address, ptep, entry);
spin_unlock(&mm->page_table_lock);
- mutex_unlock(&hugetlb_instantiation_mutex);
+
+out:
+ atomic_dec(&token);
+ if (use_mutex)
+ mutex_unlock(&hugetlb_instantiation_mutex);
return ret;
}
--
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 reply other threads:[~2006-10-26 22:17 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-26 22:17 Chen, Kenneth W [this message]
2006-10-26 22:44 ` Andrew Morton
2006-10-26 23:31 ` 'David Gibson'
2006-10-27 0:04 ` Andrew Morton
2006-10-27 3:11 ` 'David Gibson'
2006-10-27 3:35 ` Andrew Morton
2006-10-27 4:06 ` 'David Gibson'
2006-10-31 2:54 ` Chen, Kenneth W
2006-10-31 3:17 ` 'David Gibson'
2006-10-31 5:15 ` Chen, Kenneth W
2006-10-31 11:05 ` 'David Gibson'
2006-10-31 12:48 ` Hugh Dickins
2006-11-01 6:18 ` Nick Piggin
2006-11-01 10:17 ` Chen, Kenneth W
2006-11-02 3:06 ` Nick Piggin
2006-11-02 2:29 ` 'David Gibson'
2006-10-27 1:47 ` 'David Gibson'
2006-10-30 20:55 ` Adam Litke
2006-10-26 23:47 ` 'David Gibson'
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='000101c6f94c$8138c590$ff0da8c0@amr.corp.intel.com' \
--to=kenneth.w.chen@intel.com \
--cc=agl@us.ibm.com \
--cc=akpm@osdl.org \
--cc=bill.irwin@oracle.com \
--cc=christoph@schroedinger.engr.sgi.com \
--cc=david@gibson.dropbear.id.au \
--cc=hugh@veritas.com \
--cc=linux-mm@kvack.org \
/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