From: Anand Jain <anand.jain@oracle.com>
To: dsterba@suse.cz, David Sterba <dsterba@suse.com>,
linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 00/11] Cleanup dev-replace locking
Date: Thu, 4 Oct 2018 09:06:01 +0800 [thread overview]
Message-ID: <91a85e18-161f-5da0-825e-0468867af3f4@oracle.com> (raw)
In-Reply-To: <20180927110646.GP3255@twin.jikos.cz>
On 09/27/2018 07:06 PM, David Sterba wrote:
> On Fri, Sep 07, 2018 at 04:54:59PM +0200, David Sterba wrote:
>> The series peels off the custom locking that's used for dev-replace and
>> uses read-write semaphore in the end.
>>
>> I've mainly focused on correctness and haven't measured the performance
>> effects. There should be none as the blocking and waiting was merely
>> open coding what the rw semaphore does, but without the fairness. The
>> overall number of locks taken is low, there's a lots of IO in between so
>> even if new scheme is slower, I don't expect any dramatic change.
>
> Mixed results. The btrfs/011 is a test that usually takes long time
> (around 1000 sec on my test box) and I have a long list of run times to
> compare. There this patchset does not show any problems. However on a VM
> with 8 CPUs, this goes from similar times (1000 sec) to several hours,
> without apparent reason. The is other low activity on the system, but so
> this is with testing other patchsets and the times are not that bad.
>
> So, I'm going to merge the first part of the patchset that does not
> switch the locking primitives to the semaphores, more analysis needed.
>
I have reviewed/tested all in this set and it looks good to me.
So Reviewed-by: Anand Jain <anand.jain@oracle.com>
I do observer btrfs/011 taking longer time to complete (200sec more) and
Null pointer dereference even without this patch set, tracing back lead
to conclusion, that
v4.17 is good.
v4.18-rc1 is bad.
And in particular these commit ids..
7a932516f55c Merge tag 'vfs-timespec64' of
git://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground
e7655d2b2546 Merge tag 'for-4.18-part2-tag' of
git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux
15eefe2a99b2 Merge branch 'vfs_timespec64' of
https://github.com/deepa-hub/vfs into vfs-timespec64
6396bb221514 treewide: kzalloc() -> kcalloc()
next prev parent reply other threads:[~2018-10-04 1:06 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-07 14:54 [PATCH 00/11] Cleanup dev-replace locking David Sterba
2018-09-07 14:55 ` [PATCH 01/11] btrfs: remove btrfs_dev_replace::read_locks David Sterba
2018-09-07 14:55 ` [PATCH 02/11] btrfs: open code btrfs_dev_replace_clear_lock_blocking David Sterba
2018-09-07 14:55 ` [PATCH 03/11] btrfs: open code btrfs_dev_replace_stats_inc David Sterba
2018-09-07 21:02 ` Omar Sandoval
2018-09-07 14:55 ` [PATCH 04/11] btrfs: open code btrfs_after_dev_replace_commit David Sterba
2018-09-07 21:03 ` Omar Sandoval
2018-09-07 14:55 ` [PATCH 05/11] btrfs: dev-replace: avoid useless lock on error handling path David Sterba
2018-09-07 21:06 ` Omar Sandoval
2018-09-14 16:53 ` David Sterba
2018-09-07 14:55 ` [PATCH 06/11] btrfs: dev-replace: move replace members out of fs_info David Sterba
2018-09-07 21:09 ` Omar Sandoval
2018-09-07 14:55 ` [PATCH 07/11] btrfs: dev-replace: remove pointless assert in write unlock David Sterba
2018-09-07 14:55 ` [PATCH 08/11] btrfs: reada: reorder dev-replace locks before radix tree preload David Sterba
2018-09-07 14:55 ` [PATCH 09/11] btrfs: dev-replace: swich locking to rw semaphore David Sterba
2018-09-07 14:55 ` [PATCH 10/11] btrfs: dev-replace: remove custom read/write blocking scheme David Sterba
2018-09-07 14:55 ` [PATCH 11/11] btrfs: dev-replace: open code trivial locking helpers David Sterba
2018-09-27 11:06 ` [PATCH 00/11] Cleanup dev-replace locking David Sterba
2018-10-04 1:06 ` Anand Jain [this message]
2018-10-04 10:13 ` David Sterba
2018-10-05 8:58 ` Anand Jain
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=91a85e18-161f-5da0-825e-0468867af3f4@oracle.com \
--to=anand.jain@oracle.com \
--cc=dsterba@suse.com \
--cc=dsterba@suse.cz \
--cc=linux-btrfs@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.