mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: William Lee Irwin <wli@holomorphy.com>, Andrew Morton <akpm@osdl.org>
Cc: libhugetlbfs-deve@lists.sourceforge.net, linux-kernel@vger.kernel.org
Subject: Handle updating of ACCESSED and DIRTY in hugetlb_fault()
Date: Wed, 20 Aug 2008 10:36:45 +1000	[thread overview]
Message-ID: <20080820003645.GC26611@yookeroo.seuss> (raw)

The page fault path for normal pages, if the fault is neither a
no-page fault nor a write-protect fault, will update the DIRTY and
ACCESSED bits in the page table appropriately.

The hugepage fault path, however, does not do this, handling only
no-page or write-protect type faults.  It assumes that either the
ACCESSED and DIRTY bits are irrelevant for hugepages (usually true,
since they are never swapped) or that they are handled by the arch
code.

This is inconvenient for some software-loaded TLB architectures, where
the _PAGE_ACCESSED (_PAGE_DIRTY) bits need to be set to enable read
(write) access to the page at the TLB miss.  This could be worked
around in the arch TLB miss code, but the TLB miss fast path can be
made simple more easily if the hugetlb_fault() path handles this, as
the normal page fault path does.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>

---

RFC, looking to merge for 2.6.28.

Index: working-2.6/mm/hugetlb.c
===================================================================
--- working-2.6.orig/mm/hugetlb.c	2008-08-19 15:14:51.000000000 +1000
+++ working-2.6/mm/hugetlb.c	2008-08-19 15:28:27.000000000 +1000
@@ -2008,7 +2008,7 @@ int hugetlb_fault(struct mm_struct *mm, 
 	entry = huge_ptep_get(ptep);
 	if (huge_pte_none(entry)) {
 		ret = hugetlb_no_page(mm, vma, address, ptep, write_access);
-		goto out_unlock;
+		goto out_mutex;
 	}
 
 	ret = 0;
@@ -2024,7 +2024,7 @@ int hugetlb_fault(struct mm_struct *mm, 
 	if (write_access && !pte_write(entry)) {
 		if (vma_needs_reservation(h, vma, address) < 0) {
 			ret = VM_FAULT_OOM;
-			goto out_unlock;
+			goto out_mutex;
 		}
 
 		if (!(vma->vm_flags & VM_SHARED))
@@ -2034,10 +2034,23 @@ int hugetlb_fault(struct mm_struct *mm, 
 
 	spin_lock(&mm->page_table_lock);
 	/* Check for a racing update before calling hugetlb_cow */
-	if (likely(pte_same(entry, huge_ptep_get(ptep))))
-		if (write_access && !pte_write(entry))
+	if (unlikely(!pte_same(entry, huge_ptep_get(ptep))))
+		goto out_page_table_lock;
+
+
+	if (write_access) {
+		if (!pte_write(entry)) {
 			ret = hugetlb_cow(mm, vma, address, ptep, entry,
 							pagecache_page);
+			goto out_page_table_lock;
+		}
+		entry = pte_mkdirty(entry);
+	}
+	entry = pte_mkyoung(entry);
+	if (huge_ptep_set_access_flags(vma, address, ptep, entry, write_access))
+		update_mmu_cache(vma, address, entry);
+
+out_page_table_lock:
 	spin_unlock(&mm->page_table_lock);
 
 	if (pagecache_page) {
@@ -2045,7 +2058,7 @@ int hugetlb_fault(struct mm_struct *mm, 
 		put_page(pagecache_page);
 	}
 
-out_unlock:
+out_mutex:
 	mutex_unlock(&hugetlb_instantiation_mutex);
 
 	return ret;

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

                 reply	other threads:[~2008-08-20  0:39 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20080820003645.GC26611@yookeroo.seuss \
    --to=david@gibson.dropbear.id.au \
    --cc=akpm@osdl.org \
    --cc=libhugetlbfs-deve@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=wli@holomorphy.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

all inboxes | Powered by JetHome®