[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20200917213312.GF7954@magnolia>
Date: Thu, 17 Sep 2020 14:33:12 -0700
From: "Darrick J. Wong" <darrick.wong@...cle.com>
To: Christoph Hellwig <hch@...radead.org>
Cc: Brian Foster <bfoster@...hat.com>,
Dave Chinner <david@...morbit.com>,
Ritesh Harjani <riteshh@...ux.ibm.com>,
Anju T Sudhakar <anju@...ux.vnet.ibm.com>,
linux-xfs@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org, willy@...radead.org,
minlei@...hat.com
Subject: Re: [PATCH] iomap: Fix the write_count in iomap_add_to_ioend().
On Thu, Sep 17, 2020 at 03:48:04PM +0100, Christoph Hellwig wrote:
> 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.
/me hasn't totally been following this thread, but iomap will also
aggregate the ioend completions; do we need to cap that to keep
latencies down? I was assuming that amortization was always favorable,
but maybe not?
--D
Powered by blists - more mailing lists