linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Mark Fasheh <mark.fasheh@oracle.com>,
	Linux Memory Management <linux-mm@kvack.org>,
	linux-fsdevel@vger.kernel.org,
	linux-kernel <linux-kernel@vger.kernel.org>,
	OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>,
	Andrew Morton <akpm@google.com>
Subject: Re: Status of buffered write path (deadlock fixes)
Date: Wed, 13 Dec 2006 15:03:28 +1100	[thread overview]
Message-ID: <457F7B90.5000900@yahoo.com.au> (raw)
In-Reply-To: <1165977064.5695.38.camel@lade.trondhjem.org>

Trond Myklebust wrote:
> On Wed, 2006-12-13 at 12:56 +1100, Nick Piggin wrote:
> 
>>Note that these pages should be *really* rare. Definitely even for normal
>>filesystems I think RMW would use too much bandwidth if it were required
>>for any significant number of writes.
> 
> 
> If file "foo" exists on the server, and contains data, then something
> like
> 
> fd = open("foo", O_WRONLY);
> write(fd, "1", 1);
> 
> should never need to trigger a read. That's a fairly common workload
> when you think about it (happens all the time in apps that do random
> write).

Right. What I'm currently looking at doing in that case is two copies,
first into a temporary buffer. Unfortunate, but we'll see what the
performance looks like.

>>I don't want to mandate anything just yet, so I'm just going through our
>>options. The first two options (remove, and RMW) are probably trickier
>>than they need to be, given the 3rd option available (temp buffer). Given
>>your input, I'm increasingly thinking that the best course of action would
>>be to fix this with the temp buffer and look at improving that later if it
>>causes a noticable slowdown.
> 
> 
> What is the generic problem you are trying to resolve? I saw something
> fly by about a reader filling the !uptodate page while the writer is
> updating it: how is that going to happen if the writer has the page
> locked?

The problem is that you can't take a pagefault while holding the page
lock. You can deadlock against another page, the same page, or the
mmap_sem.

> AFAIK the only thing that can modify the page if it is locked (aside
> from the process that has locked it) is a process that has the page
> mmapped(). However mmapped pages are always uptodate, right?

That's right (modulo the pagefault vs invalidate race bug).

But we need to unlock the destination page in order to be able to take
a pagefault to bring the source user memory uptodate. If the page is
not uptodate, then a read might see uninitialised data.

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 


  reply	other threads:[~2006-12-13  4:04 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-05  6:52 Status of buffered write path (deadlock fixes) Nick Piggin
2006-12-07 19:55 ` Mark Fasheh
2006-12-08  3:28   ` Nick Piggin
2006-12-08 23:48     ` Mark Fasheh
2006-12-11  9:11       ` Nick Piggin
2006-12-11 14:20         ` Nick Piggin
2006-12-11 15:52         ` Nick Piggin
2006-12-11 16:12           ` Steven Whitehouse
2006-12-11 16:39             ` Nick Piggin
2006-12-11 17:18               ` Steven Whitehouse
2006-12-12 22:31           ` Mark Fasheh
2006-12-13  0:53             ` Nick Piggin
2006-12-13  1:47               ` Trond Myklebust
2006-12-13  1:56                 ` Nick Piggin
2006-12-13  2:31                   ` Trond Myklebust
2006-12-13  4:03                     ` Nick Piggin [this message]
2006-12-13 12:21                       ` Trond Myklebust
2006-12-13 13:49                     ` Peter Staubach
2006-12-13 13:55                       ` Trond Myklebust
2006-12-11 18:17 ` OGAWA Hirofumi

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=457F7B90.5000900@yahoo.com.au \
    --to=nickpiggin@yahoo.com.au \
    --cc=akpm@google.com \
    --cc=hirofumi@mail.parknet.co.jp \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mark.fasheh@oracle.com \
    --cc=trond.myklebust@fys.uio.no \
    /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;
as well as URLs for NNTP newsgroup(s).