On Tue, Apr 14, 2020 at 07:06:25PM +1000, Dave Chinner wrote:
> 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?
Oh. Heh. I forgot we had one of those.
--D
> -Dave.
> --
> Dave Chinner
> david@xxxxxxxxxxxxx
