On Mon, Apr 13, 2020 at 05:31:21PM -0700, Darrick J. Wong wrote:
> On Mon, Apr 13, 2020 at 08:31:09AM -0400, Brian Foster wrote:
> > On Sun, Apr 12, 2020 at 06:10:17PM -0700, Darrick J. Wong wrote:
> > > From: Darrick J. Wong <darrick.wong@xxxxxxxxxx>
> > >
> > > Move the inode dirty data flushing to a workqueue so that multiple
> > > threads can take advantage of a single thread's flush work. The
> > > ratelimiting technique was not successful, because threads that skipped
> > > the inode flush scan due to ratelimiting would ENOSPC early and
> > > apparently now there are complaints about that. So make everyone wait.
> > >
> > > Fixes: bdd4ee4f8407 ("xfs: ratelimit inode flush on buffered write ENOSPC")
> > > Signed-off-by: Darrick J. Wong <darrick.wong@xxxxxxxxxx>
> > > ---
> >
> > Seems reasonable in general, but do we really want to to dump a longish
> > running filesystem sync to the system workqueue? It looks like there are
> > a lot of existing users so I can't really tell if there are major
> > restrictions or not, but it seems risk of disruption is higher than
> > necessary if we dump one or more full fs syncs to it..
>
> Hmm, I guess I should look at the other flush_work user (the CIL) to see
> if there's any potential for conflicts. IIRC the system workqueue will
> spawn more threads if someone blocks too long, but maybe we ought to
> use system_long_wq for these kinds of things...
Why isn't this being put on the mp->m_sync_workqueue?
-Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
