On 23.08.2018 00:38, Liu Bo wrote:
> hmm, looks like the current mutex with adaptive spinning doesn't offer
> read/write version, meaning we're not able to simple drop rwlock.
What about rw_semaphores?
On Tue, Aug 21, 2018 at 02:48:47PM -0400, Chris Mason wrote:
> On 21 Aug 2018, at 14:15, Liu Bo wrote:
>
> > On Tue, Aug 21, 2018 at 01:54:11PM -0400, Chris Mason wrote:
> > > On 16 Aug 2018, at 17:07, Liu Bo wrote:
> > >
> > > > The lock contention on btree nodes (esp. root node) is apparently
On Tue, Aug 21, 2018 at 02:48:47PM -0400, Chris Mason wrote:
> On 21 Aug 2018, at 14:15, Liu Bo wrote:
>
> > On Tue, Aug 21, 2018 at 01:54:11PM -0400, Chris Mason wrote:
> > > On 16 Aug 2018, at 17:07, Liu Bo wrote:
> > >
> > > > The lock contention on btree nodes (esp. root node) is apparently
On Tue, Aug 21, 2018 at 08:35:30PM +0200, Holger Hoffstätte wrote:
> On 08/21/18 20:15, Liu Bo wrote:
> > I just realize that patch 2 can result in softlockup as
> > btrfs_search_slot() may return a path with all nodes being in spinning
> > lock, and if the callers want to sleep, we're in trouble.
On 21 Aug 2018, at 14:15, Liu Bo wrote:
On Tue, Aug 21, 2018 at 01:54:11PM -0400, Chris Mason wrote:
On 16 Aug 2018, at 17:07, Liu Bo wrote:
The lock contention on btree nodes (esp. root node) is apparently a
bottleneck when there're multiple readers and writers concurrently
trying to access
On 08/21/18 20:15, Liu Bo wrote:
I just realize that patch 2 can result in softlockup as
btrfs_search_slot() may return a path with all nodes being in spinning
lock, and if the callers want to sleep, we're in trouble. I've
removed patch 2 and am re-running the test (xfstests, fsmark and
On Tue, Aug 21, 2018 at 01:54:11PM -0400, Chris Mason wrote:
> On 16 Aug 2018, at 17:07, Liu Bo wrote:
>
> > The lock contention on btree nodes (esp. root node) is apparently a
> > bottleneck when there're multiple readers and writers concurrently
> > trying to access them. Unfortunately this is
On 16 Aug 2018, at 17:07, Liu Bo wrote:
The lock contention on btree nodes (esp. root node) is apparently a
bottleneck when there're multiple readers and writers concurrently
trying to access them. Unfortunately this is by design and it's not
easy to fix it unless with some complex changes,
The lock contention on btree nodes (esp. root node) is apparently a
bottleneck when there're multiple readers and writers concurrently
trying to access them. Unfortunately this is by design and it's not
easy to fix it unless with some complex changes, however, there is
still some room.
With a
