linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [RFC v2 PATCH 0/3] xfs: automatic relogging experiment
@ 2019-11-22 18:19 Brian Foster
  2019-11-22 18:19 ` [RFC v2 PATCH 1/3] xfs: set t_task at wait time instead of alloc time Brian Foster
                   ` (3 more replies)
  0 siblings, 4 replies; 6+ messages in thread
From: Brian Foster @ 2019-11-22 18:19 UTC (permalink / raw)
  To: linux-xfs

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@redhat.com/

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


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2019-11-27 15:12 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-11-22 18:19 [RFC v2 PATCH 0/3] xfs: automatic relogging experiment Brian Foster
2019-11-22 18:19 ` [RFC v2 PATCH 1/3] xfs: set t_task at wait time instead of alloc time Brian Foster
2019-11-22 18:19 ` [RFC v2 PATCH 2/3] xfs: prototype automatic intent relogging mechanism Brian Foster
2019-11-22 18:19 ` [RFC v2 PATCH 3/3] xfs: automatically relog quotaoff start intent Brian Foster
2019-11-25 18:55 ` [RFC v3 PATCH] xfs: automatic relogging experiment Brian Foster
2019-11-27 15:12   ` Brian Foster

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).