From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Mike Waychison <mikew@google.com>
Cc: Andrew Morton <akpm@osdl.org>,
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: Wed, 20 Sep 2006 12:02:57 +1000 [thread overview]
Message-ID: <1158717778.6002.234.camel@localhost.localdomain> (raw)
In-Reply-To: <451095F1.3000304@google.com>
> I think the disconnect here is that the retries in the mmap_sem case and
> the returning short for a signal are two different beasts, but they
> would both want to use a NOPAGE_RETRY return code.
>
> In the case of a signal, we definitely want to return back to userspace
> and deliver it. However, for dropping the mmap_sem while waiting for
> the synchronous IO, it's a lot easier to directly rerun the fault
> handler so that we can make another pass without allowing the for the
> drop (avoiding livelock).
I'm not sure I see what your exactly livelock scenario is...
> If we were to return to userspace after having dropped mmap_sem (without
> updating pte, because mm/vmas may change) we would lose major vs minor
> fault accounting as well.
My point is we do the looping in the fault handler if the PTE is still
absent and there is no signal pending and we return to userspace (and
drop the mmap_sem) if any of these criterias is met. We might want to
add a cond_resched() in the first case too.
Wouldn't that solve the livelock issue ?
Ben.
--
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:[~2006-09-20 2:02 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-14 22:55 Benjamin Herrenschmidt
2006-09-15 0:19 ` Linus Torvalds
2006-09-15 7:11 ` Andrew Morton
2006-09-15 7:35 ` Andrew Morton
2006-09-15 13:30 ` Hugh Dickins
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:59 ` Andrew Morton
2006-09-20 0:06 ` Benjamin Herrenschmidt
2006-09-20 0:05 ` Benjamin Herrenschmidt
2006-09-20 0:21 ` Andrew Morton
2006-09-20 1:57 ` Benjamin Herrenschmidt
2006-09-20 3:05 ` Andrew Morton
2006-09-20 5:04 ` Benjamin Herrenschmidt
2006-09-20 5:26 ` Andrew Morton
2006-09-20 6:54 ` Benjamin Herrenschmidt
2006-09-20 17:53 ` Andrew Morton
2006-09-21 22:05 ` Benjamin Herrenschmidt
2006-09-21 22:41 ` Andrew Morton
2006-09-21 23:09 ` Benjamin Herrenschmidt
2006-09-23 14:21 ` Hugh Dickins
2006-09-23 19:46 ` Andrew Morton
2006-09-23 22:35 ` Benjamin Herrenschmidt
2006-09-20 5:06 ` Benjamin Herrenschmidt
2006-09-20 1:14 ` Mike Waychison
2006-09-20 2:02 ` Benjamin Herrenschmidt [this message]
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=1158717778.6002.234.camel@localhost.localdomain \
--to=benh@kernel.crashing.org \
--cc=akpm@osdl.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox