From: Theodore Ts'o <tytso@mit.edu>
To: Andrey Sidorov <qrxd43@motorola.com>
Cc: linux-ext4@vger.kernel.org
Subject: Re: [PATCH RFC 2/2] ext4: speed-up releasing blocks on commit
Date: Tue, 18 Sep 2012 00:17:14 -0400 [thread overview]
Message-ID: <20120918041714.GD32195@thunk.org> (raw)
In-Reply-To: <CAA0+VHwvmr5Pi+86tcEsZ7L8gE30UdwivBTFy0_Q8bEgxw_uqw@mail.gmail.com>
On Tue, Sep 18, 2012 at 01:00:58AM +0400, Andrey Sidorov wrote:
> Improve mb_free_blocks speed by clearing bits all at once instead of
> going one by one. Rebuild buddy bitmap by going up only once per range
> instead of once per block.
> This algorithm relies on buddy bitmap to be correct and it can't
> handle ranges with already freed blocks producing incorrect results in
> these conditions.
> I will add checking for error cases is to be added as soon as I get
> some inputs on how to do that (and if this patch has some interest at
> all).
Thanks, this patch is interesting as well --- but yes, we do need to
make sure the changes will not make any potential inconsistency in the
buddy bitmaps any worse that they already are.
The main thing we need to consider for the buddy bitmap code is that
it's one of the more subtle and complex bits of code in the ext4 code
base. So changing it is always scary that there is some interesting
edge case that isn't quite right.
That means the two things we need to consider are (a) adding sanity
checking code which we can compile in or out to test to make sure the
right thing happens for all of the various corner cases, and (b)
making sure we do the right thing even if the buddy bitmaps have
gotten corrupted in memory some how.
Regards,
- Ted
prev parent reply other threads:[~2012-09-18 4:17 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-17 21:00 [PATCH RFC 2/2] ext4: speed-up releasing blocks on commit Andrey Sidorov
2012-09-18 4:17 ` Theodore Ts'o [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=20120918041714.GD32195@thunk.org \
--to=tytso@mit.edu \
--cc=linux-ext4@vger.kernel.org \
--cc=qrxd43@motorola.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;
as well as URLs for NNTP newsgroup(s).