From: Nick Piggin <npiggin@suse.de>
To: Linux Filesystems <linux-fsdevel@vger.kernel.org>
Cc: Mark Fasheh <mark.fasheh@oracle.com>, Miklos Szeredi <miklos@szeredi.hu>
Subject: 2.6.21-rc6 new aops patchset
Date: Thu, 12 Apr 2007 06:48:52 +0200 [thread overview]
Message-ID: <20070412044852.GA31961@wotan.suse.de> (raw)
http://www.kernel.org/pub/linux/kernel/people/npiggin/patches/new-aops/
2.6.21-rc6-new-aops*
New aops patchset against 2.6.21-rc6.
Reworked the cont helpers to be better aligned with the old scheme.
This unbroke reiserfs (hopefully the only showstopper), and made fat
conversion simpler.
Converted most of the cont_prepare_write filesystems (about half a dozen).
affs and hfsplus still call ->prepare_write in parts, which makes them
slightly less than trivial.
Converted block_dev and jffs2 to new aops.
Converted hostfs and smbfs, optimised things along the way.
Convert rd to new aops. This was interesting because the new aops make
it trivial to keep rd pagecache off the LRU, so I did that too.
Bugfixes for tmpfs and loop (which was not using the new aops, so I
didn't notice the tmpfs breakage).
Switched ext2's directory manipulation to the new pagecache accessors.
Did some performance testing of the fuse_perform_write implementation.
Result with a passthrough filesystem onto a backing tmpfs directory is that
bulk (1MB) writes are nearly 4 times faster (256MB/s vs 71MB/s), because
FUSE can send larger requests to userspace. Block based filesystems will
tend to be less dramatic, but could still be significant if block allocation
is batched, for example.
Issues:
perform_write still here for the moment (conversion from perform_write aop
implementation to write fop shouldn't be too hard anyway, but I'll sort
this out before it gets into mainline).
nobh still unconverted (old nobh ops still work, they'll just be using the
slow usercopy path. ext3 doesn't use nobh any more). I'm inclined to keep
ignoring nobh for now, because we're already up to 40 patches. I'd like to
try improving nobh, but this isn't the right patchset to do it in.
Many of the trivial conversions are untested. Need to convert others
(eg. reiserfs).
Need to think about how to merge this.
next reply other threads:[~2007-04-12 4:48 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-12 4:48 Nick Piggin [this message]
2007-04-12 16:37 ` 2.6.21-rc6 new aops patchset Badari Pulavarty
2007-04-12 23:25 ` Nick Piggin
2007-04-13 16:42 ` Badari Pulavarty
2007-04-14 0:52 ` Nick Piggin
2007-04-17 18:41 ` Badari Pulavarty
2007-04-18 5:04 ` Nick Piggin
2007-04-12 17:05 ` Miklos Szeredi
2007-04-12 23:41 ` Nick Piggin
2007-04-12 17:27 ` Mark Fasheh
2007-04-12 23:45 ` Nick Piggin
2007-04-17 0:19 ` Mark Fasheh
2007-04-17 5:59 ` Nick Piggin
2007-04-17 9:33 ` Christoph Hellwig
2007-04-17 9:47 ` Nick Piggin
2007-04-17 9:58 ` Christoph Hellwig
2007-04-17 11:18 ` 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=20070412044852.GA31961@wotan.suse.de \
--to=npiggin@suse.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=mark.fasheh@oracle.com \
--cc=miklos@szeredi.hu \
/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