From: "Amir G." <amir73il@users.sourceforge.net>
To: "Ted Ts'o" <tytso@mit.edu>
Cc: linux-ext4@vger.kernel.org, Yongqiang Yang <xiaoqiangnk@gmail.com>
Subject: Re: [PATCH v2 5/5] ext4: remove alloc_semp
Date: Tue, 10 May 2011 21:20:58 +0300 [thread overview]
Message-ID: <BANLkTimQbrOVDpgZGmhT9-rzMWEjVgkf4A@mail.gmail.com> (raw)
In-Reply-To: <20110510132910.GA6933@thunk.org>
On Tue, May 10, 2011 at 4:29 PM, Ted Ts'o <tytso@mit.edu> wrote:
> On Thu, Mar 24, 2011 at 06:58:13PM +0200, amir73il@users.sourceforge.net wrote:
>> From: Amir Goldstein <amir73il@users.sf.net>
>>
>> After taking care of all group init races, all that remains is to
>> remove alloc_semp from ext4_allocation_context and ext4_buddy structs.
>>
>> Signed-off-by: Amir Goldstein <amir73il@users.sf.net>
>
> Hey Amir,
>
> What sort of testing have you done with this patch series? In
> particular, have you tried doing online resizes while the file system
> is heavily loaded?
I have tested many small resizes, not block group aligned and added
debug prints in mballoc.c to verify that in-memory bb_free and group_desc
bg_free_blocks remain in sync.
Sorry, I did not run the same tests under heavy load.
I would think that one would need to know exactly how to load his
system to make that load relevant to this test, rather than blindly
fsstressing the system.
If you have specific ideas for testing please let us know.
I think Yongqiang could run these tests.
Regarding the "risk" of online resize with this patch,
if you look at ext4_add_groupblocks() in it's new form,
you will surely notice that it is an exact replica of ext4_free_blocks()
with lots of irrelevant code removed, so the code path of online resize,
is essentially the same as the code patch of freeing any range of blocks
with regards to buddy cache init and locks.
It was actually possible to alter ext4_free_blocks() a bit and reuse it
to do most of the work done by ext4_add_groupblocks(), but I did not
want to make these changes to ext4_free_blocks(). it's your call if
you think that would be better off.
Anyway, I was kind of hoping for another pair of eyes to validate my changes
when I first posted these patches. So what do you say?
Does the core change to synchronize ext4_mb_init_group() by locking
the buddy pages look reasonable to you?
You were the one who suggested that approach in the first place.
Amir.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2011-05-10 18:20 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-24 16:58 [PATCHSET v2] ext4: removal of alloc_sem locks from block allocation paths amir73il
2011-03-24 16:58 ` [PATCH v2 1/5] ext4: move ext4_add_groupblocks() to mballoc.c amir73il
2011-05-09 14:54 ` Ted Ts'o
2011-05-09 14:59 ` [PATCH 1/2] " Theodore Ts'o
2011-05-09 14:59 ` [PATCH 2/2] ext4: remove unneeded ext4_journal_get_undo_access Theodore Ts'o
2011-05-09 16:01 ` [PATCH v2 1/5] ext4: move ext4_add_groupblocks() to mballoc.c Amir G.
2011-05-09 16:28 ` Yongqiang Yang
2011-03-24 16:58 ` [PATCH v2 2/5] ext4: implement ext4_add_groupblocks() by freeing blocks amir73il
2011-03-24 16:58 ` [PATCH v2 3/5] ext4: synchronize ext4_mb_init_group() with buddy page lock amir73il
2011-03-24 16:58 ` [PATCH v2 4/5] ext4: teach ext4_mb_init_cache() to skip uptodate buddy caches amir73il
2011-03-24 16:58 ` [PATCH v2 5/5] ext4: remove alloc_semp amir73il
2011-05-10 13:29 ` Ted Ts'o
2011-05-10 18:20 ` Amir G. [this message]
2011-05-03 15:47 ` [PATCHSET v2] ext4: removal of alloc_sem locks from block allocation paths Amir G.
2011-05-10 13:48 ` Lukas Czerner
2011-05-10 18:30 ` Amir G.
2011-05-10 18:43 ` Lukas Czerner
2011-05-10 18:58 ` Amir G.
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=BANLkTimQbrOVDpgZGmhT9-rzMWEjVgkf4A@mail.gmail.com \
--to=amir73il@users.sourceforge.net \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
--cc=xiaoqiangnk@gmail.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).