Hi all, Here's a second pass at the automatic relogging experiment. The first pass tagged the log item for relog and stole reservation from unrelated transactions to opportunistically relog items, all within the log subsystem. The primary feedback to that approach was to consider a transaction function callback and concerns about reservation stealing. This version somewhat accommodates those concerns, but still leaves some open questions around broader usage. In short, this version introduces a separate workqueue context for committing and rolling transactions for relogged items and a hook to trigger a relog based on the item being committed to the AIL. The relog state (including log reservation for the relog) is tracked via the log item. Only the log ticket from the caller transaction is regranted and tracked to avoid processing open transactions through separate contexts. This is essentially an open-coded transaction roll without the need for a duplicate transaction. While this seems to work reasonably well for the simple case of quotaoff, there are still some open issues to resolve around formalizing such a mechanism for broader use. Firstly, the quotaoff patch just ties into the existing ->iop_committed() callback since that is currently unused, but the queue relog call could just as easily be made directly from the AIL commit code. IOW, the whole callback thing seems kind of like a solution looking for a problem in this context. With external tracking of relogged items, all we really need here fundamentally is a notification that the CIL context has committed. Another caveat is that this approach seems much more cumbersome and inefficient with respect to batching relogs of unrelated items. Rather than collect all unrelated items in a single transaction, we'd have a separate tracking structure, log ticket (which regrants the caller's entire reservation) and independent roll/regrant for each potential set of items. I can see value in the simplicity and flexibility of use in terms of being able to potentially register an already constructed transaction for automatic relogging, but I question whether that suits our use case(s). All in all, I think this is still pretty raw and needs some more thought on the design (or perhaps requirements) front. I could see this going anywhere from something more low level like the previous version where we could have a relogged items list (RIL) associated with the CIL and require initial transactions donate real relog reservation to something more like this approach where we have some separate context queueing/rolling relog transactions based on log subsystem events. I suspect there are capability considerations for either end of that spectrum. For example, it might be harder to auto relog anything but intents with the RIL approach where there is no transaction to own item locks, etc., but do we currently have a use case to relog anything besides QUOTAOFF and EFIs? If not, I lean more toward the more simple, low level approach (at least for now), but I could be convinced otherwise. Thoughts on any of this appreciated. Brian rfcv2: - Different approach based on workqueue and transaction rolling. rfc: https://lore.kernel.org/linux-xfs/20191024172850.7698-1-bfoster@xxxxxxxxxx/ Brian Foster (3): xfs: set t_task at wait time instead of alloc time xfs: prototype automatic intent relogging mechanism xfs: automatically relog quotaoff start intent fs/xfs/Makefile | 1 + fs/xfs/libxfs/xfs_trans_resv.c | 3 +- fs/xfs/xfs_dquot_item.c | 13 ++++ fs/xfs/xfs_log.c | 11 ++- fs/xfs/xfs_log_priv.h | 1 + fs/xfs/xfs_qm_syscalls.c | 9 ++- fs/xfs/xfs_trans.c | 2 +- fs/xfs/xfs_trans.h | 13 ++++ fs/xfs/xfs_trans_relog.c | 130 +++++++++++++++++++++++++++++++++ 9 files changed, 179 insertions(+), 4 deletions(-) create mode 100644 fs/xfs/xfs_trans_relog.c -- 2.20.1
