[0/3] xfs: CIL improvements

Message

Dave Chinner Feb. 23, 2021, 5:32 a.m. UTC

HI folks,

The following patches improve the behaviour of the CIL and increase
the processing capacity available for pushing changes into the
journal.

The first patch is an interface change, fixing something I did when
first introducing delayed logging to ease the understanding of the
change the CIL placed on the rest of the code. That was to "pretend"
that the log items still recorded the log sequence numbers that they
were comitted to, and that these LSNs could be passed to
xfs_log_force_lsn() to force the log to a certain LSN.

Truth is that the CIL hands out CIL sequence numbers to log items on
commits, not journal log sequence numbers. The LSNs are now
essentially and internal log and AIL implementation detail,
everything else that runs transactions and interfaces with log items
to force the log store around CIL sequences.

Hence the first patch converts xfs_log_force_lsn() to
xfs_log_force_seq() and all the high level stuff to refer to
sequence numbers rather than LSNs.

The second patch gets rid of severe latency issues that the AIL can
see due to having to force the log to unpin items. While it is
running a log force, it does nothing and hence we can run out of log
space before the log force returns and the AIL starts pushing again.

The AIL only needs to push on the CIL to get items unpinned, and it
doesn't need to wait for it to complete, either, before it continues
onwards trying to push out items to disk. The AIL will back off when
it reaches target, so it doesn't need to wait on log forces to back
off when there are pinned items in the AIL.

Hence this patch adds a mechanism to do an async push on the CIL
that does not block and changes the AIL to use it. This results in
the AIL backing off on it's own short timeouts and trying to make
progress repeatedly instead of stalling for seconds waiting for log
forces to complete.

The last patch is a fix to the pipelining of the CIL pushes. The
pipelining isn't working as intended, it's actually serialising and
resulting in the CIL push work being CPU bound and limiting the rate
at which items can be pushed to the journal. It is also creating
excessive push latency where the CIL fills and hits the hard
throttle while waiting for the push work to finish the current push
and then start on the new push and swap in a new CIL context that
can be committed to.

Essentially, the problem is an implementation problem, not a design
flaw. The implementation has a single work attached to the CIL,
meaning we can only have a single outstanding push work in progress
at any time. The workqueue can handle more, but we only have a
single work. So the fix is to move the work to the CIL context so we
can queue and process multiple works at the same time, thereby
actually allowing the CIL push work to pipeline in the intended
manner.

Cheers,

Dave.