From: Dave Chinner <dgc@kernel.org>
To: John Garry <john.garry@linux.dev>
Cc: John Garry <john.g.garry@oracle.com>,
"Darrick J. Wong" <djwong@kernel.org>,
Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>,
"linux-xfs@vger.kernel.org" <linux-xfs@vger.kernel.org>
Subject: Re: [bug report] fstests generic/774 hang again
Date: Fri, 18 Sep 2026 07:20:04 +1000 [thread overview]
Message-ID: <aqxZhKvsHFAyUM5k@dread> (raw)
In-Reply-To: <e651832b-75bc-4520-a45e-b79cd986d175@linux.dev>
On Thu, Sep 17, 2026 at 09:28:15AM +0100, John Garry wrote:
> On 9/16/26 23:23, Dave Chinner wrote:
> > On Wed, Sep 16, 2026 at 11:23:16AM +0100, John Garry wrote:
> > > On 15/09/2026 16:41, John Garry wrote:
> > > > On 9/15/26 15:50, Darrick J. Wong wrote:
> > > > > > thanks
> > > > > >
> > > > > > About the kernel code, I am wondering if using IOMAP_DIO_FORCE_WAIT for
> > > > > > CoW-based atomics could help avoid this issue as we seem to be
> > > > > > bogged down
> > > > > > in lock contention.
> > > > > Which lock is being contended, anyway? It looks like the ILOCK?
> > > >
> > > > Yeah, I think so Re. ilock. I had some perf data illustrating this from
> > > > last year, which I can't seem to find, so I will re-generate it.
> > >
> > > Here is perf call graph snippet when running fio with 72x threads issuing
> > > 4KB atomic writes on 1MB file:
> > >
> > > --50.46%--xfs_file_dio_write_atomic
> > > |
> > > |--37.19%--iomap_dio_rw
> > > | |
> > > | --37.14%--__iomap_dio_rw
> > > | |
> > > | --36.50%--iomap_iter
> > > | |
> > > | --36.49%--xfs_atomic_write_cow_iomap_next
> > > | |
> > > | |--27.34%--xfs_ilock
> > > | | |
> > > | | --27.34%--down_write
> > > | | |
> > > | | --27.28%--rwsem_down_write_slowpath
> > > | | |
> > > | | |--24.65%--osq_lock
> > > | | |
> > > | | --2.35%--rwsem_spin_on_owner
> > > | |
> > > | |--7.62%--xfs_trans_alloc_inode
> > > | | |
> > > | | --7.59%--xfs_ilock
> >
> > Where's the other half of the lock contention?
>
> I was expecting xfs_reflink_end_atomic_cow() -> xfs_ilock() to be a point of
> contention as well, but it does not show up. I suppose that it because all
> those threads at completion stage are sleeping.
>
> However, there is this which I omitted:
>
> --13.21%--xfs_file_write_checks
> |
> --13.18%--kiocb_modified
> |
> --13.17%--file_update_time_flags
> |
> --13.16%--xfs_vn_update_time
> |
> --12.99%--xfs_ilock
> |
> --12.98%--down_write
Fair enough, I'd expect that from the all the threads blocked on the
lock there in the hung task output.
....
> JFYI, I have another log for a similar hang which we see one thread deadlock
> for log space, below.
Looks very similar. So, same questiosn about log size, etc.
-Dave.
--
Dave Chinner
dgc@kernel.org
next prev parent reply other threads:[~2026-09-17 21:20 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-15 9:34 [bug report] fstests generic/774 hang again Shin'ichiro Kawasaki
2026-09-15 10:00 ` John Garry
2026-09-15 11:48 ` Shin'ichiro Kawasaki
2026-09-15 14:48 ` John Garry
2026-09-15 14:50 ` Darrick J. Wong
2026-09-15 15:41 ` John Garry
2026-09-16 10:23 ` John Garry
2026-09-16 22:23 ` Dave Chinner
2026-09-17 8:28 ` John Garry
2026-09-17 21:20 ` Dave Chinner [this message]
2026-09-17 6:30 ` Shin'ichiro Kawasaki
2026-09-16 2:53 ` Shin'ichiro Kawasaki
2026-09-16 21:45 ` Dave Chinner
2026-09-17 6:52 ` Shin'ichiro Kawasaki
2026-09-17 10:45 ` Shin'ichiro Kawasaki
2026-09-17 21:24 ` Dave Chinner
2026-09-19 11:53 ` Shin'ichiro Kawasaki
2026-09-21 22:05 ` Dave Chinner
2026-09-25 1:32 ` Shin'ichiro Kawasaki
2026-09-27 21:30 ` Dave Chinner
2026-09-28 2:45 ` Darrick J. Wong
2026-09-22 0:28 ` Darrick J. Wong
2026-09-25 1:38 ` Shin'ichiro Kawasaki
2026-09-25 23:03 ` Darrick J. Wong
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=aqxZhKvsHFAyUM5k@dread \
--to=dgc@kernel.org \
--cc=djwong@kernel.org \
--cc=john.g.garry@oracle.com \
--cc=john.garry@linux.dev \
--cc=linux-xfs@vger.kernel.org \
--cc=shinichiro.kawasaki@wdc.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