From: Ted Ts'o <tytso@mit.edu>
To: Sami Liedes <sami.liedes@iki.fi>
Cc: Andreas Dilger <adilger@dilger.ca>, linux-ext4@vger.kernel.org
Subject: Re: [PATCH 4/5] libext2fs: Implement ext2fs_find_first_zero_generic_bmap().
Date: Mon, 26 Mar 2012 11:34:31 -0400 [thread overview]
Message-ID: <20120326153431.GC15027@thunk.org> (raw)
In-Reply-To: <20120326135355.GB2180@cc.hut.fi>
On Mon, Mar 26, 2012 at 04:53:56PM +0300, Sami Liedes wrote:
> > So I plan to pull in your patch series and then we can further enhance
> > this with iterator support afterwards. Sami, if you'd be interested
> > in implementing iterators, that would be great!
>
> Just to be on the same page, what is the motivation for iterators? Is
> it performance, making the code cleaner or facilitating further
> functionality?
It's a little of all three. For example, in e2fsck's pass #5, we
currently test each bit, one at a time. The code paths are quite
complex, but given that we're already using an rbtree for block and
inode bitmaps in e2fsck, using a find_first_set() function could
significantly improve performance. (We can't really use an iterator
since we need to stop at each block group boundary to check the bg
summary values, but that's where using a find_first_set() with an
"upto" field would do what we want.)
I'll note by the way that it's possible for resize2fs, if we implement
find_first_set() and find_first_zero() for rbtree bitmaps, using
rbtree bitmaps could be even faster, since even with your
optimizations, if there are large blocks of unset bitmaps, we have to
check every single memory location in a bitarray, where as a rbtree
bitmap is much more space compact and would also be faster from a
"find_first_set" standpoint.
There are a few other places where it would make the code cleaner, and
where I might switch to using an rbtree-backed bitmap instead of a
sorted array implementation, but that's a secondary concern.
Cheers,
- Ted
next prev parent reply other threads:[~2012-03-26 15:34 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-10 21:33 [PATCH 0/5] Make filesystem shrinking faster and less CPU-intensive Sami Liedes
2012-03-10 21:34 ` [PATCH 1/5] libext2fs: Move a modulo operation out of a hot loop Sami Liedes
2012-03-11 9:50 ` Andreas Dilger
2012-03-10 21:35 ` [PATCH 2/5] resize2fs: Use EXT2_FLAG_64BITS Sami Liedes
2012-03-10 21:36 ` [PATCH 3/5] libext2fs: Document EXT2_FLAG_64BITS in ext2fs_open2() Sami Liedes
2012-03-10 21:37 ` [PATCH 4/5] libext2fs: Implement ext2fs_find_first_zero_generic_bmap() Sami Liedes
2012-03-11 9:51 ` Andreas Dilger
2012-03-12 19:15 ` Sami Liedes
2012-03-12 23:09 ` Andreas Dilger
2012-03-23 22:33 ` Ted Ts'o
2012-03-26 13:53 ` Sami Liedes
2012-03-26 15:34 ` Ted Ts'o [this message]
2012-03-26 2:39 ` Ted Ts'o
2012-03-10 21:38 ` [PATCH 5/5] libext2fs: Implement fast find_first_zero() for bitarray bitmaps Sami Liedes
2012-03-26 2:34 ` Ted Ts'o
2012-03-26 13:22 ` Sami Liedes
2012-03-26 15:26 ` Ted Ts'o
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=20120326153431.GC15027@thunk.org \
--to=tytso@mit.edu \
--cc=adilger@dilger.ca \
--cc=linux-ext4@vger.kernel.org \
--cc=sami.liedes@iki.fi \
/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).