From: Theodore Tso <tytso@mit.edu>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH, RFC] ext4: Replace hackish ext4_mb_poll_new_transaction with commit callback
Date: Fri, 17 Oct 2008 08:25:52 -0400 [thread overview]
Message-ID: <20081017122552.GC21503@mit.edu> (raw)
In-Reply-To: <20081017100214.GB11557@mit.edu>
On Fri, Oct 17, 2008 at 06:02:14AM -0400, Theodore Tso wrote:
> >
> > Why not use journal commit callback patch from andreas
> > (MID:20080929201752.GN10950@webber.adilger.int
> > http://article.gmane.org/gmane.comp.file-systems.ext4/9148)
> >
> > The patch you sent will allows only one call back to be registered.
>
> Thanks for reminding me about that; I had completely forgotten about
> Andreas' patch. Sure, I'll respin the patch to use his extension.
I looked more closely at Andreas' patch, and it's really not a good
fit for what we want to do. The problem is that it is designed to
attach arbitrary callbacks on a per transaction basis. Each time you
add a callback you need to allocate a stucture, and then it gets
chained onto a inked list.
For what we need for mballoc, not only is it massive overkill, but
every single time we try to free blocks, we would have to and then
search the list to see the remove_committed_blocks() callback was or
wasn't on the list yet, and if it wasn't then allocate a chunk of
memory to hold the struct journal_callback data structure and call
journal_callback_set() function.
Furthermore, to get the locking right and to avoid race conditions,
we'd have to add a _journal_callback_set() function which doesn't take
the spinlock, and then take the spinlock ourselves, search the linked
list, allocate the memory, call _journal_callback_set(), and then
release the spinlock.
It was at about this point that I decided it Just Wasn't Worth It.
What I added was a dead-simple per-journal commit callback, with no
additional memory allocations (and requirement to do error handling if
the memory allocation fails), no need to take a spinlock before
manually adding the call back to each transaction handle, no need to
search the linked list to see if we have an entry on the linked list
already, etc.
If in the future we need a true per-transaction handle commit
callback, we can add this; but I think it still makes more sense to
keep the per-journal commit callback. After all, as it stands the
current patch results in a net reduction of 46 lines of code. Adding
all of this machinery would erase take far more than the savings by
removing ext4_mb_poll_new_transaction().
- Ted
next prev parent reply other threads:[~2008-10-17 12:26 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-17 0:02 [PATCH, RFC] ext4: Replace hackish ext4_mb_poll_new_transaction with commit callback Theodore Ts'o
2008-10-17 6:04 ` Aneesh Kumar K.V
2008-10-17 10:02 ` Theodore Tso
2008-10-17 12:25 ` Theodore Tso [this message]
2008-10-17 20:27 ` Joel Becker
2008-10-19 22:49 ` Andreas Dilger
2008-10-20 1:13 ` Theodore Tso
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=20081017122552.GC21503@mit.edu \
--to=tytso@mit.edu \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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