linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Amir G." <amir73il@users.sourceforge.net>
To: Lukas Czerner <lczerner@redhat.com>
Cc: tytso@mit.edu, linux-ext4@vger.kernel.org
Subject: Re: [PATCHSET v2] ext4: removal of alloc_sem locks from block allocation paths
Date: Tue, 10 May 2011 21:30:16 +0300	[thread overview]
Message-ID: <BANLkTimuBxQCQa3437ZzB0ynAmuWhTduLQ@mail.gmail.com> (raw)
In-Reply-To: <alpine.LFD.2.00.1105101543570.17175@dhcp-27-109.brq.redhat.com>

On Tue, May 10, 2011 at 4:48 PM, Lukas Czerner <lczerner@redhat.com> wrote:
> On Thu, 24 Mar 2011, amir73il@users.sourceforge.net wrote:
>
>> The purpose of this patch set is the removal of grp->alloc_sem locks
>> from block allocation paths.
>>
>> The resulting code is cleaner and should perform better in concurrent
>> allocating tasks workloads.
> Hi Amir,
>
> Do you have any performance numbers indicating performance improvement
> in concurrent allocations ? The only point where I can see taking
> write semaphore is in filesystem resize code. Or am I missing something ?

Yes, you are. down_write is also taken when initializing a block group
buddy cache for the first time (NEED_INIT flag is set).
Anyway, I do NOT have any performance number since this wasn't the purpose of
this work. This work was done for snapshots, but I do think that as I wrote:
1. The resulting code is cleaner
2. Getting rid of an unneeded semaphore in allocation path can only do good
to performance, but I certainly don't have the kind of high scalability testing
setup to show the performance improvements if there are any.

>
> Thanks!
> -Lukas
>
>>
>> I ran several xfstests runs with these patches (4K and 1K block size).
>> I tried several online resizes and verifyed that both in-core and on-disk
>> group counters are correct.
>>
>> v2->v1:
>> - fix silly bug in patch 4/5 that triggers BUG_ON(incore == NULL)
>> - replace get_undo_access() with get_write_access()
>> - ran xfstests with block size 1K (where 2 groups share a buddy page)
>>
>> [PATCH v2 1/5] ext4: move ext4_add_groupblocks() to mballoc.c
>> [PATCH v2 2/5] ext4: implement ext4_add_groupblocks() by freeing blocks
>> [PATCH v2 3/5] ext4: synchronize ext4_mb_init_group() with buddy page lock
>> [PATCH v2 4/5] ext4: teach ext4_mb_init_cache() to skip uptodate buddy caches
>> [PATCH v2 5/5] ext4: remove alloc_semp
>>
>> --
>> 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
>>
>
> --
>
--
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

  reply	other threads:[~2011-05-10 18:30 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.
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. [this message]
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=BANLkTimuBxQCQa3437ZzB0ynAmuWhTduLQ@mail.gmail.com \
    --to=amir73il@users.sourceforge.net \
    --cc=lczerner@redhat.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tytso@mit.edu \
    /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).