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.
