From: Adam Litke <agl@us.ibm.com>
To: Andi Kleen <ak@suse.de>
Cc: linux-mm@kvack.org, christoph@lameter.com,
kenneth.w.chen@intel.com, david@gibson.dropbear.id.au
Subject: Re: [PATCH 0/4] Demand faunting for huge pages
Date: Thu, 18 Aug 2005 15:29:30 -0500 [thread overview]
Message-ID: <1124396970.3152.7.camel@localhost.localdomain> (raw)
In-Reply-To: <20050817210431.GR3996@wotan.suse.de>
On Wed, 2005-08-17 at 23:04 +0200, Andi Kleen wrote:
> Also I still think your get_user_pages approach is questionable.
I am pretty sure that my approach is safe and merely removes an
optimization. Hopefully the following better states my reasons for
thinking so. If anyone else who was involved in the demand fault
discussion when it went around the last time (see below) could chime in
I think it would help further clarify the issue.
---
Initial Post (Thu, 18 Aug 2005)
In preparation for hugetlb demand faulting, remove this get_user_pages()
optimization. Since huge pages will no longer be prefaulted, we can't assume
that the huge ptes are established and hence, calling follow_hugetlb_page() is
not valid.
With the follow_hugetlb_page() call removed, the normal code path will be
triggered. follow_page() will either use follow_huge_addr() or
follow_huge_pmd() to check for a previously faulted "page" to return. When
this fails (ie. with demand faults), __handle_mm_fault() gets called which
invokes the hugetlb_fault() handler to instantiate the huge page.
This patch doesn't make a lot of sense by itself, but I've broken it out to
facilitate discussion on this specific element of the demand fault changes.
While coding this up, I referenced previous discussion on this topic starting
at http://lkml.org/lkml/2004/4/13/176 , which contains more opinions about the
correctness of this approach.
Diffed against 2.6.13-rc6-git7
Signed-off-by: Adam Litke <agl@us.ibm.com>
---
memory.c | 5 -----
1 files changed, 5 deletions(-)
diff -upN reference/mm/memory.c current/mm/memory.c
--- reference/mm/memory.c
+++ current/mm/memory.c
@@ -937,11 +937,6 @@ int get_user_pages(struct task_struct *t
|| !(flags & vma->vm_flags))
return i ? : -EFAULT;
- if (is_vm_hugetlb_page(vma)) {
- i = follow_hugetlb_page(mm, vma, pages, vmas,
- &start, &len, i);
- continue;
- }
spin_lock(&mm->page_table_lock);
do {
int write_access = write;
--
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>
prev parent reply other threads:[~2005-08-18 20:34 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-17 18:56 Adam Litke
2005-08-17 19:03 ` [PATCH 1/4] x86-pte_huge Adam Litke
2005-08-17 19:18 ` Dave Hansen
2005-08-17 19:27 ` Adam Litke
2005-08-17 19:03 ` [PATCH 2/4] x86-move-stale-pgtable Adam Litke
2005-08-17 19:04 ` [PATCH 3/4] x86-walk-check Adam Litke
2005-08-17 19:41 ` Dave Hansen
2005-08-17 19:05 ` [PATCH 4/4] htlb-fault Adam Litke
2005-08-17 21:04 ` [PATCH 0/4] Demand faunting for huge pages Andi Kleen
2005-08-18 0:33 ` David Gibson
2005-08-18 0:35 ` Andi Kleen
2005-08-18 20:33 ` Adam Litke
2005-08-18 15:29 ` Ray Bryant
2005-08-18 20:29 ` Adam Litke [this message]
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=1124396970.3152.7.camel@localhost.localdomain \
--to=agl@us.ibm.com \
--cc=ak@suse.de \
--cc=christoph@lameter.com \
--cc=david@gibson.dropbear.id.au \
--cc=kenneth.w.chen@intel.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