Linux XFS filesystem development
 help / color / mirror / Atom feed
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

  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