linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Brian Foster <bfoster@redhat.com>
Cc: Trond Myklebust <trondmy@hammerspace.com>,
	"david@fromorbit.com" <david@fromorbit.com>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"trondmy@kernel.org" <trondmy@kernel.org>,
	"hch@infradead.org" <hch@infradead.org>,
	"axboe@kernel.dk" <axboe@kernel.dk>,
	"linux-xfs@vger.kernel.org" <linux-xfs@vger.kernel.org>,
	"willy@infradead.org" <willy@infradead.org>
Subject: Re: [PATCH] iomap: Address soft lockup in iomap_finish_ioend()
Date: Tue, 4 Jan 2022 11:23:21 -0800	[thread overview]
Message-ID: <20220104192321.GF31606@magnolia> (raw)
In-Reply-To: <YdRNasL3WFugVe8c@bfoster>

On Tue, Jan 04, 2022 at 08:36:42AM -0500, Brian Foster wrote:
> On Sat, Jan 01, 2022 at 05:39:45PM +0000, Trond Myklebust wrote:
> ...
> > 
> > Fair enough. As long as someone is working on a solution, then I'm
> > happy. Just a couple of things:
> > 
> > Firstly, we've verified that the cond_resched() in the bio loop does
> > suffice to resolve the issue with XFS, which would tend to confirm what
> > you're saying above about the underlying issue being the ioend chain
> > length.
> > 
> > Secondly, note that we've tested this issue with a variety of older
> > kernels, including 4.18.x, 5.1.x and 5.15.x, so please bear in mind
> > that it would be useful for any fix to be backward portable through the
> > stable mechanism.
> > 
> 
> I've sent a couple or so different variants of this in the past. The
> last I believe was here [1], but still never seemed to go anywhere
> (despite having reviews on the first couple patches). That one was
> essentially a sequence of adding a cond_resched() call in the iomap code
> to address the soft lockup warning followed by capping the ioend size
> for latency reasons.

Huh.  I wonder why I didn't ever merge that?  I said I was going to do
that for 5.14 and ... never did.  ISTR Matthew saying something about
wanting to key the decision off of the number of pages/folios we'd have
to touch, and then musing about adding QOS metrics, me getting fussy
about that, trying to figure out if there was a way to make
iomap_finish_page_writeback cheaper, and ...

<checks notes>

...and decided that since the folio merge was imminent (HA!) I would
merge it after all the dust settled.  Add several months of Things I
Still Cannot Talk About and now it's 2022. :(

Ah, ok, I'll go reply elsewhere in the thread since I think my thinking
on all this has evolved somewhat since then.

--D

> 
> Brian
> 
> [1] https://lore.kernel.org/linux-xfs/20210517171722.1266878-1-bfoster@redhat.com/
> 
> > 
> > Thanks, and Happy New Year!
> > 
> >   Trond
> > 
> > -- 
> > Trond Myklebust
> > Linux NFS client maintainer, Hammerspace
> > trond.myklebust@hammerspace.com
> > 
> > 
> 

  reply	other threads:[~2022-01-04 19:23 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-30 19:35 [PATCH] iomap: Address soft lockup in iomap_finish_ioend() trondmy
2021-12-30 21:24 ` Jens Axboe
2021-12-30 22:25   ` Trond Myklebust
2021-12-30 22:27     ` Jens Axboe
2021-12-30 22:55       ` Trond Myklebust
2021-12-31  1:42 ` Matthew Wilcox
2021-12-31  6:16   ` Trond Myklebust
2022-01-01  3:55     ` Dave Chinner
2022-01-01 17:39       ` Trond Myklebust
2022-01-03 22:03         ` Dave Chinner
2022-01-04  0:04           ` Trond Myklebust
2022-01-04  1:22             ` Dave Chinner
2022-01-04  3:01               ` Trond Myklebust
2022-01-04  7:08               ` hch
2022-01-04 18:08                 ` Matthew Wilcox
2022-01-04 18:14                   ` hch
2022-01-04 19:22                     ` Darrick J. Wong
2022-01-04 21:52                       ` Dave Chinner
2022-01-04 23:12                         ` Darrick J. Wong
2022-01-05  2:10                           ` Dave Chinner
2022-01-05 13:56                             ` Brian Foster
2022-01-05 22:04                               ` Dave Chinner
2022-01-06 16:44                                 ` Brian Foster
2022-01-10  8:18                                   ` Dave Chinner
2022-01-10 17:45                                     ` Brian Foster
2022-01-10 18:11                                       ` hch
2022-01-11 14:33                                       ` Trond Myklebust
2022-01-05 13:42                           ` hch
2022-01-04 21:16                 ` Dave Chinner
2022-01-05 13:43                   ` hch
2022-01-05 22:34                     ` Dave Chinner
2022-01-05  2:09               ` Trond Myklebust
2022-01-05 20:45                 ` Trond Myklebust
2022-01-05 22:48                   ` Dave Chinner
2022-01-05 23:29                     ` Trond Myklebust
2022-01-06  0:01                     ` Darrick J. Wong
2022-01-09 23:09                       ` Dave Chinner
2022-01-06 18:36                     ` Trond Myklebust
2022-01-06 18:38                       ` Trond Myklebust
2022-01-06 20:07                       ` Brian Foster
2022-01-07  3:08                         ` Trond Myklebust
2022-01-07 15:15                           ` Brian Foster
2022-01-09 23:34                       ` Dave Chinner
2022-01-10 23:37                       ` Dave Chinner
2022-01-11  0:08                         ` Dave Chinner
2022-01-13 17:01                         ` Trond Myklebust
2022-01-17 17:24                           ` Trond Myklebust
2022-01-17 17:36                             ` Darrick J. Wong
2022-01-04 13:36         ` Brian Foster
2022-01-04 19:23           ` Darrick J. Wong [this message]
2022-01-05  2:31 ` [iomap] f5934dda54: BUG:sleeping_function_called_from_invalid_context_at_fs/iomap/buffered-io.c kernel test robot

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=20220104192321.GF31606@magnolia \
    --to=djwong@kernel.org \
    --cc=axboe@kernel.dk \
    --cc=bfoster@redhat.com \
    --cc=david@fromorbit.com \
    --cc=hch@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=trondmy@hammerspace.com \
    --cc=trondmy@kernel.org \
    --cc=willy@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).