[RFC,0/2] xfs: non-blocking inodegc pushes

Message

Dave Chinner May 24, 2022, 6:38 a.m. UTC

Hi folks,

I've had time to forward port the non-blocking inodegc push changes
I had in a different LOD to the current for-next tree. I've run it
through fstests auto group a couple of times and it hasn't caused
any space accounting related failures on the machines I've run it
on.

The first patch introduces the bound maximum work start time for the
inodegc queues - it's short, only 10ms (IIRC), but we don't want to
delay inodegc for an arbitrarily long period of time. However, it
means that work always starts quickly and so that reduces the need
for statfs() to have to wait for background inodegc to start and
complete to catch space "freed" by recent unlinks.

The second patch converts statfs to use a "push" rather than a
"flush". The push simply schedules any pending work that hasn't yet
timed out to run immediately and returns. It does not wait for the
inodegc work to complete - that's what a flush does, and that's what
caused all the problems for statfs(). Hence statfs() is converted to
push semantics at the same time, thereby removing the blocking
behaviour it currently has.

This should prevent a large amount of the issues that Chris has been
seeing with lots of processes stuck in statfs() - that will no long
happen. The only time user processes should get stuck now is when
the inodegc throttle kicks in (unlinks only at this point) or if we
are waiting for a lock a long running inodegc operation holds to be
released. We had those specific problems before background inodegc -
they manifested as unkillable unlink operations that had every
backed up on them instead of background inodegc that has everything
backed up on them.

Hence I think these patches largely restore the status quo that we
had before the background inodegc code was added.

Comments, thoughts and testing appreciated.

Cheers,

Dave.