linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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>

  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