All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Andrew Morton <akpm@osdl.org>
Cc: Hugh Dickins <hugh@veritas.com>,
	Mike Waychison <mikew@google.com>,
	linux-mm@kvack.org,
	Linux Kernel list <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@osdl.org>
Subject: Re: [RFC] page fault retry with NOPAGE_RETRY
Date: Sun, 24 Sep 2006 08:35:36 +1000	[thread overview]
Message-ID: <1159050936.14486.115.camel@localhost.localdomain> (raw)
In-Reply-To: <20060923124618.e5ef3a51.akpm@osdl.org>


> Perhaps we should concentrate on that for now.  Did we have a patch to look
> at?

Only a hand written proto-patch. Below is a real (but untested) one.
Note that there might be still issues when called from get_user_pages()
which of course won't go back to userland. For the two usage scenario I
have in mind, it should be ok though. One (a signal pending) will loop
back in until the resource is available, the other (no_page() inserts
the PTE itself) is just fine. For the former case, I've added a
cond_resched() to the loop, we might want to look into adding the info
of wether we are coming from get_user_pages() vs. do_page_fault() to
these new arguments you want to add to page fault handlers. That would
allow in our case to do a non-interruptibe sleep when caused by
get_user_pages().

---

Add a way for a no_page() handler to request a retry of the faulting
instruction. It goes back to userland on page faults and just tries
again in get_user_pages(). I added a cond_resched() in the loop in that
later case.

Signed-off-by: Benjamin Herrenchmidt <benh@kernel.crashing.org>

Index: linux-work/include/linux/mm.h
===================================================================
--- linux-work.orig/include/linux/mm.h	2006-08-30 08:51:21.000000000 +1000
+++ linux-work/include/linux/mm.h	2006-09-24 08:25:33.000000000 +1000
@@ -623,6 +623,7 @@
  */
 #define NOPAGE_SIGBUS	(NULL)
 #define NOPAGE_OOM	((struct page *) (-1))
+#define NOPAGE_RETRY	((struct page *) (-2))
 
 /*
  * Different kinds of faults, as returned by handle_mm_fault().
Index: linux-work/mm/memory.c
===================================================================
--- linux-work.orig/mm/memory.c	2006-08-17 16:16:06.000000000 +1000
+++ linux-work/mm/memory.c	2006-09-24 08:34:09.000000000 +1000
@@ -1081,6 +1081,7 @@
 				default:
 					BUG();
 				}
+				cond_resched();
 			}
 			if (pages) {
 				pages[i] = page;
@@ -2117,11 +2118,13 @@
 	 * after the next truncate_count read.
 	 */
 
-	/* no page was available -- either SIGBUS or OOM */
-	if (new_page == NOPAGE_SIGBUS)
+	/* no page was available -- either SIGBUS, OOM or RETRY */
+	if (unlikely(new_page == NOPAGE_SIGBUS))
 		return VM_FAULT_SIGBUS;
-	if (new_page == NOPAGE_OOM)
+	else if (unlikely(new_page == NOPAGE_OOM))
 		return VM_FAULT_OOM;
+	else if (unlikely(new_page == NOPAGE_RETRY))
+		return VM_FAULT_MINOR;
 
 	/*
 	 * Should we do an early C-O-W break?



WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Andrew Morton <akpm@osdl.org>
Cc: Hugh Dickins <hugh@veritas.com>,
	Mike Waychison <mikew@google.com>,
	linux-mm@kvack.org,
	Linux Kernel list <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@osdl.org>
Subject: Re: [RFC] page fault retry with NOPAGE_RETRY
Date: Sun, 24 Sep 2006 08:35:36 +1000	[thread overview]
Message-ID: <1159050936.14486.115.camel@localhost.localdomain> (raw)
In-Reply-To: <20060923124618.e5ef3a51.akpm@osdl.org>

> Perhaps we should concentrate on that for now.  Did we have a patch to look
> at?

Only a hand written proto-patch. Below is a real (but untested) one.
Note that there might be still issues when called from get_user_pages()
which of course won't go back to userland. For the two usage scenario I
have in mind, it should be ok though. One (a signal pending) will loop
back in until the resource is available, the other (no_page() inserts
the PTE itself) is just fine. For the former case, I've added a
cond_resched() to the loop, we might want to look into adding the info
of wether we are coming from get_user_pages() vs. do_page_fault() to
these new arguments you want to add to page fault handlers. That would
allow in our case to do a non-interruptibe sleep when caused by
get_user_pages().

---

Add a way for a no_page() handler to request a retry of the faulting
instruction. It goes back to userland on page faults and just tries
again in get_user_pages(). I added a cond_resched() in the loop in that
later case.

Signed-off-by: Benjamin Herrenchmidt <benh@kernel.crashing.org>

Index: linux-work/include/linux/mm.h
===================================================================
--- linux-work.orig/include/linux/mm.h	2006-08-30 08:51:21.000000000 +1000
+++ linux-work/include/linux/mm.h	2006-09-24 08:25:33.000000000 +1000
@@ -623,6 +623,7 @@
  */
 #define NOPAGE_SIGBUS	(NULL)
 #define NOPAGE_OOM	((struct page *) (-1))
+#define NOPAGE_RETRY	((struct page *) (-2))
 
 /*
  * Different kinds of faults, as returned by handle_mm_fault().
Index: linux-work/mm/memory.c
===================================================================
--- linux-work.orig/mm/memory.c	2006-08-17 16:16:06.000000000 +1000
+++ linux-work/mm/memory.c	2006-09-24 08:34:09.000000000 +1000
@@ -1081,6 +1081,7 @@
 				default:
 					BUG();
 				}
+				cond_resched();
 			}
 			if (pages) {
 				pages[i] = page;
@@ -2117,11 +2118,13 @@
 	 * after the next truncate_count read.
 	 */
 
-	/* no page was available -- either SIGBUS or OOM */
-	if (new_page == NOPAGE_SIGBUS)
+	/* no page was available -- either SIGBUS, OOM or RETRY */
+	if (unlikely(new_page == NOPAGE_SIGBUS))
 		return VM_FAULT_SIGBUS;
-	if (new_page == NOPAGE_OOM)
+	else if (unlikely(new_page == NOPAGE_OOM))
 		return VM_FAULT_OOM;
+	else if (unlikely(new_page == NOPAGE_RETRY))
+		return VM_FAULT_MINOR;
 
 	/*
 	 * Should we do an early C-O-W break?


--
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>

  reply	other threads:[~2006-09-23 22:35 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-14 22:55 [RFC] page fault retry with NOPAGE_RETRY Benjamin Herrenschmidt
2006-09-14 22:55 ` Benjamin Herrenschmidt
2006-09-15  0:19 ` Linus Torvalds
2006-09-15  0:19   ` Linus Torvalds
2006-09-15  7:11 ` Andrew Morton
2006-09-15  7:11   ` Andrew Morton
2006-09-15  7:35   ` Andrew Morton
2006-09-15  7:35     ` Andrew Morton
2006-09-15 13:30     ` Hugh Dickins
2006-09-15 13:30       ` Hugh Dickins
2006-09-16  1:03       ` Benjamin Herrenschmidt
2006-09-16  1:03         ` Benjamin Herrenschmidt
2006-09-19 23:35   ` Mike Waychison
2006-09-19 23:50     ` Benjamin Herrenschmidt
2006-09-19 23:50       ` Benjamin Herrenschmidt
2006-09-19 23:59       ` Andrew Morton
2006-09-19 23:59         ` Andrew Morton
2006-09-20  0:06         ` Benjamin Herrenschmidt
2006-09-20  0:06           ` Benjamin Herrenschmidt
2006-09-20  0:05       ` Benjamin Herrenschmidt
2006-09-20  0:05         ` Benjamin Herrenschmidt
2006-09-20  0:21         ` Andrew Morton
2006-09-20  0:21           ` Andrew Morton
2006-09-20  1:57           ` Benjamin Herrenschmidt
2006-09-20  1:57             ` Benjamin Herrenschmidt
2006-09-20  3:05             ` Andrew Morton
2006-09-20  3:05               ` Andrew Morton
2006-09-20  5:04               ` Benjamin Herrenschmidt
2006-09-20  5:04                 ` Benjamin Herrenschmidt
2006-09-20  5:26                 ` Andrew Morton
2006-09-20  5:26                   ` Andrew Morton
2006-09-20  6:54                   ` Benjamin Herrenschmidt
2006-09-20  6:54                     ` Benjamin Herrenschmidt
2006-09-20 17:53                     ` Andrew Morton
2006-09-20 17:53                       ` Andrew Morton
2006-09-21 22:05                       ` Benjamin Herrenschmidt
2006-09-21 22:05                         ` Benjamin Herrenschmidt
2006-09-21 22:41                         ` Andrew Morton
2006-09-21 22:41                           ` Andrew Morton
2006-09-21 23:09                           ` Benjamin Herrenschmidt
2006-09-21 23:09                             ` Benjamin Herrenschmidt
2006-09-23 14:21                       ` Hugh Dickins
2006-09-23 14:21                         ` Hugh Dickins
2006-09-23 19:46                         ` Andrew Morton
2006-09-23 19:46                           ` Andrew Morton
2006-09-23 22:35                           ` Benjamin Herrenschmidt [this message]
2006-09-23 22:35                             ` Benjamin Herrenschmidt
2006-09-20  5:06               ` Benjamin Herrenschmidt
2006-09-20  5:06                 ` Benjamin Herrenschmidt
2006-09-20  1:14       ` Mike Waychison
2006-09-20  1:14         ` Mike Waychison
2006-09-20  2:02         ` Benjamin Herrenschmidt
2006-09-20  2:02           ` Benjamin Herrenschmidt
2006-09-15 21:35 ` Arnd Bergmann
2006-09-15 21:35   ` Arnd Bergmann

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=1159050936.14486.115.camel@localhost.localdomain \
    --to=benh@kernel.crashing.org \
    --cc=akpm@osdl.org \
    --cc=hugh@veritas.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mikew@google.com \
    --cc=torvalds@osdl.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.