From: Christoph Hellwig <hch@infradead.org>
To: Brian Foster <bfoster@redhat.com>
Cc: Christoph Hellwig <hch@infradead.org>,
"Darrick J. Wong" <darrick.wong@oracle.com>,
Dave Chinner <david@fromorbit.com>,
Ritesh Harjani <riteshh@linux.ibm.com>,
Anju T Sudhakar <anju@linux.vnet.ibm.com>,
linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, willy@infradead.org,
minlei@redhat.com
Subject: Re: [PATCH] iomap: Fix the write_count in iomap_add_to_ioend().
Date: Thu, 17 Sep 2020 15:48:04 +0100 [thread overview]
Message-ID: <20200917144804.GA31389@infradead.org> (raw)
In-Reply-To: <20200917104219.GA1811187@bfoster>
On Thu, Sep 17, 2020 at 06:42:19AM -0400, Brian Foster wrote:
> That wouldn't address the latency concern Dave brought up. That said, I
> have no issue with this as a targeted solution for the softlockup issue.
> iomap_finish_ioend[s]() is common code for both the workqueue and
> ->bi_end_io() contexts so that would require either some kind of context
> detection (and my understanding is in_atomic() is unreliable/frowned
> upon) or a new "atomic" parameter through iomap_finish_ioend[s]() to
> indicate whether it's safe to reschedule. Preference?
True, it would not help with latency. But then again the latency
should be controlled by the writeback code not doing giant writebacks
to start with, shouldn't it?
Any XFS/iomap specific limit also would not help with the block layer
merging bios.
next prev parent reply other threads:[~2020-09-17 14:54 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-19 10:28 [PATCH] iomap: Fix the write_count in iomap_add_to_ioend() Anju T Sudhakar
2020-08-20 23:11 ` Dave Chinner
2020-08-21 4:45 ` Ritesh Harjani
2020-08-21 6:00 ` Christoph Hellwig
2020-08-21 9:09 ` Ritesh Harjani
2020-08-21 21:53 ` Dave Chinner
2020-08-22 13:13 ` Christoph Hellwig
2020-08-24 14:28 ` Brian Foster
2020-08-24 15:04 ` Christoph Hellwig
2020-08-24 15:48 ` Brian Foster
2020-08-25 0:42 ` Dave Chinner
2020-08-25 14:49 ` Brian Foster
2020-08-31 4:01 ` Ming Lei
2020-08-31 14:35 ` Brian Foster
2020-09-16 0:12 ` Darrick J. Wong
2020-09-16 8:45 ` Christoph Hellwig
2020-09-16 13:07 ` Brian Foster
2020-09-17 8:04 ` Christoph Hellwig
2020-09-17 10:42 ` Brian Foster
2020-09-17 14:48 ` Christoph Hellwig [this message]
2020-09-17 21:33 ` Darrick J. Wong
2020-09-17 23:13 ` Ming Lei
2020-08-21 6:01 ` Christoph Hellwig
2020-08-21 6:07 ` Christoph Hellwig
2020-08-21 8:53 ` Ritesh Harjani
2020-08-21 14:49 ` Jens Axboe
2020-08-21 13:31 ` Matthew Wilcox
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=20200917144804.GA31389@infradead.org \
--to=hch@infradead.org \
--cc=anju@linux.vnet.ibm.com \
--cc=bfoster@redhat.com \
--cc=darrick.wong@oracle.com \
--cc=david@fromorbit.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=minlei@redhat.com \
--cc=riteshh@linux.ibm.com \
--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).