From: Nick Piggin <npiggin@suse.de>
To: Chris Mason <chris.mason@oracle.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
Trond Myklebust <trond.myklebust@fys.uio.no>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux Memory Management List <linux-mm@kvack.org>,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH RFC] extent mapped page cache
Date: Fri, 27 Jul 2007 03:15:33 +0200 [thread overview]
Message-ID: <20070727011533.GA13939@wotan.suse.de> (raw)
In-Reply-To: <20070726090515.5fd198d1@think.oraclecorp.com>
On Thu, Jul 26, 2007 at 09:05:15AM -0400, Chris Mason wrote:
> On Thu, 26 Jul 2007 04:36:39 +0200
> Nick Piggin <npiggin@suse.de> wrote:
>
> [ are state trees a good idea? ]
>
> > > One thing it gains us is finding the start of the cluster. Even if
> > > called by kswapd, the state tree allows writepage to find the start
> > > of the cluster and send down a big bio (provided I implement
> > > trylock to avoid various deadlocks).
> >
> > That's very true, we could potentially also do that with the block
> > extent tree that I want to try with fsblock.
>
> If fsblock records and extent of 200MB, and writepage is called on a
> page in the middle of the extent, how do you walk the radix backwards
> to find the first dirty & up to date page in the range?
I mean if we also have a block extent tree between fsblock and the
filesystem's get_block (which I think could be a good idea).
So you would use that tree to find the block extent that you're in,
then use the pagecache tree dirty tag lookup from the start of that
block extent (or you could add a backward tag lookup if you just wanted
to gather a small range around the given offset). I think (haven't got
any code for this yet, mind you).
> > > I put the placeholder patches on hold because handling a corner case
> > > where userland did O_DIRECT from a mmap'd region of the same file
> > > (Linus pointed it out to me). Basically my patches had to work in
> > > 64k chunks to avoid a deadlock in get_user_pages. With the state
> > > tree, I can allow the page to be faulted in but still properly deal
> > > with it.
> >
> > Oh right, I didn't think of that one. Would you still have similar
> > issues with the external state tree? I mean, the filesystem doesn't
> > really know why the fault is taken. O_DIRECT read from a file into
> > mmapped memory of the same block in the file is almost hopeless I
> > think.
>
> Racing is fine as long as we don't deadlock or expose garbage from disk.
Hmm, OK you're probably right. I'll have to see how it looks.
> > > I'm sure we can find some river in Cambridge, winner gets to throw
> > > Axboe in.
> >
> > Very noble of you to donate your colleage to such a worthy cause.
>
> Jens is always interested in helping solve such debates. It's a
> fantastic service he provides to the community.
;)
prev parent reply other threads:[~2007-07-27 1:15 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-10 21:03 [PATCH RFC] extent mapped page cache Chris Mason
2007-07-12 7:00 ` Daniel Phillips
2007-07-18 14:18 ` Chris Mason
2007-07-24 20:00 ` Chris Mason
2007-07-24 20:03 ` [PATCH RFC] extent mapped page cache main code Chris Mason
2007-07-24 20:04 ` [PATCH RFC] ext2 extentmap support Chris Mason
2007-07-24 20:13 ` [PATCH RFC] extent mapped page cache Trond Myklebust
2007-07-24 21:25 ` Peter Zijlstra
2007-07-24 23:25 ` Chris Mason
2007-07-25 2:32 ` Nick Piggin
2007-07-25 12:18 ` Chris Mason
2007-07-26 1:37 ` Nick Piggin
2007-07-26 2:10 ` Chris Mason
2007-07-26 2:36 ` Nick Piggin
2007-07-26 7:53 ` Anton Altaparmakov
2007-07-26 13:05 ` Chris Mason
2007-07-27 1:15 ` Nick Piggin [this message]
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=20070727011533.GA13939@wotan.suse.de \
--to=npiggin@suse.de \
--cc=a.p.zijlstra@chello.nl \
--cc=chris.mason@oracle.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--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).