From: "Ted Ts'o" <tytso@mit.edu>
To: Dave Chinner <david@fromorbit.com>
Cc: Michel Lespinasse <walken@google.com>,
Peter Zijlstra <peterz@infradead.org>,
Nick Piggin <npiggin@kernel.dk>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Hugh Dickins <hughd@google.com>, Rik van Riel <riel@redhat.com>,
Kosaki Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Theodore Tso <tytso@google.com>,
Michael Rubin <mrubin@google.com>,
Suleiman Souhlal <suleiman@google.com>
Subject: Re: [PATCH 3/3] mlock: avoid dirtying pages and triggering writeback
Date: Wed, 17 Nov 2010 18:52:30 -0500 [thread overview]
Message-ID: <20101117235230.GL3290@thunk.org> (raw)
In-Reply-To: <20101117231143.GQ22876@dastard>
On Thu, Nov 18, 2010 at 10:11:43AM +1100, Dave Chinner wrote:
> I don't think ->page_mkwrite can be worked around - we need that to
> be called on the first write fault of any mmap()d page to ensure it
> is set up correctly for writeback. If we don't get write faults
> after the page is mlock()d, then we need the ->page_mkwrite() call
> during the mlock() call.
OK, so I'm not an mm hacker, so maybe I'm missing something. Could
part of this be fixed by simply sending the write faults for
mlock()'ed pages, so page_mkwrite() gets called when the page is
dirtied. Seems like a real waste to have the file system pre-allocate
all of the blocks for a mlock()'ed region. Why does mlock() have to
result in the write faults getting suppressed when the page is
actually dirtied?
- Ted
next prev parent reply other threads:[~2010-11-17 23:52 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-17 12:23 [PATCH 0/3] Avoid dirtying pages during mlock Michel Lespinasse
2010-11-17 12:23 ` [PATCH 1/3] do_wp_page: remove the 'reuse' flag Michel Lespinasse
2010-11-17 12:23 ` [PATCH 2/3] do_wp_page: clarify dirty_page handling Michel Lespinasse
2010-11-17 12:23 ` [PATCH 3/3] mlock: avoid dirtying pages and triggering writeback Michel Lespinasse
2010-11-17 12:57 ` Nick Piggin
2010-11-17 15:28 ` Peter Zijlstra
2010-11-17 22:05 ` Michel Lespinasse
2010-11-17 22:18 ` Peter Zijlstra
2010-11-17 23:11 ` Dave Chinner
2010-11-17 23:31 ` Michel Lespinasse
2010-11-19 1:46 ` Dave Chinner
2010-11-17 23:52 ` Ted Ts'o [this message]
2010-11-18 0:53 ` Andrew Morton
2010-11-18 11:03 ` Michel Lespinasse
2010-11-18 13:37 ` Christoph Hellwig
2010-11-18 17:41 ` Hugh Dickins
2010-11-19 7:23 ` Michel Lespinasse
2010-11-19 13:42 ` Theodore Tso
2010-11-19 15:06 ` Christoph Hellwig
2010-11-19 22:54 ` Andrew Morton
2010-11-19 23:22 ` Ted Ts'o
2010-11-20 0:29 ` Dustin Kirkland
2010-11-19 23:31 ` Michel Lespinasse
2010-11-19 23:54 ` Dave Chinner
2010-11-18 5:46 ` Nick Piggin
2010-11-18 10:43 ` Theodore Tso
2010-11-18 13:39 ` Christoph Hellwig
2010-11-18 18:00 ` Hugh Dickins
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=20101117235230.GL3290@thunk.org \
--to=tytso@mit.edu \
--cc=akpm@linux-foundation.org \
--cc=david@fromorbit.com \
--cc=hughd@google.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mrubin@google.com \
--cc=npiggin@kernel.dk \
--cc=peterz@infradead.org \
--cc=riel@redhat.com \
--cc=suleiman@google.com \
--cc=tytso@google.com \
--cc=walken@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