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.j...@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()
