From: Ingo Molnar <mingo@elte.hu>
To: Ying Han <yinghan@google.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
akpm <akpm@linux-foundation.org>,
Mike Waychison <mikew@google.com>,
David Rientjes <rientjes@google.com>,
Rohit Seth <rohitseth@google.com>,
Hugh Dickins <hugh@veritas.com>, Nick Piggin <npiggin@suse.de>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [RFC v1][PATCH]page_fault retry with NOPAGE_RETRY
Date: Sun, 23 Nov 2008 10:18:44 +0100 [thread overview]
Message-ID: <20081123091843.GK30453@elte.hu> (raw)
In-Reply-To: <604427e00811212247k1fe6b63u9efe8cfe37bddfb5@mail.gmail.com>
* Ying Han <yinghan@google.com> wrote:
> page fault retry with NOPAGE_RETRY
Interesting patch.
> Allow major faults to drop the mmap_sem read lock while waitting for
> synchronous disk read. This allows another thread which wishes to grab
> down_read(mmap_sem) to proceed while the current is waitting the disk IO.
Do you mean down_write()? down_read() can already be nested
arbitrarily.
> The patch flags current->flags to PF_FAULT_MAYRETRY as identify that
> the caller can tolerate the retry in the filemap_fault call patch.
>
> Benchmark is done by mmap in huge file and spaw 64 thread each
> faulting in pages in reverse order, the the result shows 8%
> porformance hit with the patch.
I suspect we also want to see the cases where this change helps?
Also, constructs like this are pretty ugly:
> +#ifdef CONFIG_X86_64
> +asmlinkage
> +#endif
> +void do_page_fault(struct pt_regs *regs, unsigned long error_code)
> +{
> + current->flags |= PF_FAULT_MAYRETRY;
> + __do_page_fault(regs, error_code);
> + current->flags &= ~PF_FAULT_MAYRETRY;
> +}
This seems to be unnecessary runtime overhead to pass in a flag to
handle_mm_fault(). Why not extend the 'write' flag of
handle_mm_fault() to also signal "arch is able to retry"?
Also, _if_ we decide that from-scratch pagefault retries are good, i
see no reason why this should not be extended to all architectures:
The retry should happen purely in the MM layer - all information is
available already, and much of do_page_fault() could generally be
moved into mm/memory.c, with one or two arch-provided standard
callbacks to express certain page fault quirks. (such as vm86 mode on
x86)
(Such a design would allow more nice cleanups - handle_mm_fault()
could inline inside the pagefault handler, etc.)
Also, a few small details. Please use this proper multi-line comment
style:
> + /*
> + * Page is already locked by someone else.
> + *
> + * We don't want to be holding down_read(mmap_sem)
> + * inside lock_page(). We use wait_on_page_lock here
> + * to just wait until the page is unlocked, but we
> + * don't really need
> + * to lock it.
> + */
Not this one:
> + /* page may be available, but we have to restart the process
> + * because mmap_sem was dropped during the ->fault */
Ingo
--
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:[~2008-11-23 9:18 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-22 6:47 Ying Han
2008-11-22 7:15 ` Andrew Morton
2008-11-23 9:18 ` Ingo Molnar [this message]
2008-11-23 18:24 ` Andrew Morton
2008-11-25 18:42 ` Ying Han
2008-11-26 12:32 ` Nick Piggin
2008-11-26 19:57 ` Mike Waychison
2008-11-27 8:55 ` Nick Piggin
2008-11-27 9:28 ` Mike Waychison
2008-11-27 10:00 ` Peter Zijlstra
2008-11-27 10:14 ` Nick Piggin
2008-11-27 19:22 ` Mike Waychison
2008-11-28 9:41 ` Nick Piggin
2008-11-28 22:46 ` Mike Waychison
2008-11-27 11:08 ` KOSAKI Motohiro
2008-11-27 19:10 ` Mike Waychison
2008-11-27 11:39 ` Török Edwin
2008-11-27 12:03 ` Nick Piggin
2008-11-27 12:21 ` Török Edwin
2008-11-27 12:32 ` Peter Zijlstra
2008-11-27 12:39 ` Nick Piggin
2008-11-27 12:52 ` Török Edwin
2008-11-27 13:05 ` Nick Piggin
2008-11-27 13:10 ` Török Edwin
2008-11-27 13:12 ` Nick Piggin
2008-11-27 13:23 ` Török Edwin
2008-11-28 12:10 ` Nick Piggin
2008-11-30 19:38 ` Török Edwin
2008-12-01 8:52 ` Nick Piggin
2008-12-01 11:13 ` Nick Piggin
2008-12-01 11:37 ` Török Edwin
2008-12-04 22:27 ` Ying Han
2008-12-05 6:50 ` Török Edwin
2008-11-27 13:08 ` Nick Piggin
2008-11-27 19:03 ` Mike Waychison
2008-11-28 9:37 ` Nick Piggin
2008-11-28 23:02 ` Mike Waychison
2008-11-30 19:54 ` Török Edwin
2008-12-01 4:50 ` Mike Waychison
2008-12-01 8:58 ` Nick Piggin
2008-12-01 11:45 ` Nick Piggin
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=20081123091843.GK30453@elte.hu \
--to=mingo@elte.hu \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=hpa@zytor.com \
--cc=hugh@veritas.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mikew@google.com \
--cc=npiggin@suse.de \
--cc=rientjes@google.com \
--cc=rohitseth@google.com \
--cc=yinghan@google.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