From: Brian Foster <bfoster@redhat.com>
To: Shan Hai <shan.hai@oracle.com>
Cc: linux-xfs@vger.kernel.org, david@fromorbit.com
Subject: Re: [PATCH 1/1] xfs: add trace points for xlog cil operations
Date: Thu, 18 May 2017 08:31:56 -0400 [thread overview]
Message-ID: <20170518123156.GB18240@bfoster.bfoster> (raw)
In-Reply-To: <1495075791-30366-1-git-send-email-shan.hai@oracle.com>
On Thu, May 18, 2017 at 10:49:51AM +0800, Shan Hai wrote:
> Signed-off-by: Shan Hai <shan.hai@oracle.com>
> ---
Any particular reason you're looking for these new tracepoints (i.e., a
commit log would be nice ;).
> fs/xfs/xfs_log_cil.c | 16 +++++++++++++++-
> fs/xfs/xfs_trace.h | 49 +++++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 64 insertions(+), 1 deletion(-)
>
> diff --git a/fs/xfs/xfs_log_cil.c b/fs/xfs/xfs_log_cil.c
> index 10309cf..f2cf0fe 100644
> --- a/fs/xfs/xfs_log_cil.c
> +++ b/fs/xfs/xfs_log_cil.c
> @@ -579,6 +579,8 @@
> xfs_trans_committed_bulk(ctx->cil->xc_log->l_ailp, ctx->lv_chain,
> ctx->start_lsn, abort);
>
> + trace_xlog_cil_committed(ctx->cil, ctx);
> +
FWIW, I think we tend to put these kind of function call tracepoints at
or towards the beginning of the associated function.
> xfs_extent_busy_sort(&ctx->busy_extents);
> xfs_extent_busy_clear(mp, &ctx->busy_extents,
> (mp->m_flags & XFS_MOUNT_DISCARD) && !abort);
> @@ -841,6 +843,8 @@
> wake_up_all(&cil->xc_commit_wait);
> spin_unlock(&cil->xc_push_lock);
>
> + trace_xlog_cil_push(cil, ctx);
> +
> /* release the hounds! */
> return xfs_log_release_iclog(log->l_mp, commit_iclog);
>
> @@ -898,7 +902,8 @@
> queue_work(log->l_mp->m_cil_workqueue, &cil->xc_push_work);
> }
> spin_unlock(&cil->xc_push_lock);
> -
> +
> + trace_xlog_cil_push_background(cil, cil->xc_ctx);
Whitespace damage above.
And do we really need the ctx information for all of these tp's? It
looks like some of these could be racy (i.e., _push_now()). FWIW,
_push_background() and _push_now() both seem like a bit of overkill to
me as well.
> }
>
> /*
> @@ -935,6 +940,8 @@
> cil->xc_push_seq = push_seq;
> queue_work(log->l_mp->m_cil_workqueue, &cil->xc_push_work);
> spin_unlock(&cil->xc_push_lock);
> +
> + trace_xlog_cil_push_now(cil, cil->xc_ctx);
> }
>
> bool
> @@ -1011,6 +1018,8 @@
> */
> xfs_trans_free_items(tp, xc_commit_lsn, false);
>
> + trace_xfs_log_commit_cil(cil, cil->xc_ctx);
> +
> xlog_cil_push_background(log);
>
> up_read(&cil->xc_ctx_lock);
> @@ -1037,6 +1046,8 @@
>
> ASSERT(sequence <= cil->xc_current_sequence);
>
> + trace_xlog_cil_force_lsn(cil, cil->xc_ctx);
> +
Racy (what stabilizes xc_ctx)? Also, why wouldn't we want the sequence
value here?
> /*
> * check to see if we need to force out the current context.
> * xlog_cil_push() handles racing pushes for the same sequence,
> @@ -1098,6 +1109,9 @@
> }
>
> spin_unlock(&cil->xc_push_lock);
> +
> + trace_xlog_cil_force_lsn_exit(cil, cil->xc_ctx);
> +
> return commit_lsn;
>
> /*
> diff --git a/fs/xfs/xfs_trace.h b/fs/xfs/xfs_trace.h
> index 0712eb7..8d0cb73 100644
> --- a/fs/xfs/xfs_trace.h
> +++ b/fs/xfs/xfs_trace.h
> @@ -37,6 +37,8 @@
> struct xlog_recover_item;
> struct xfs_buf_log_format;
> struct xfs_inode_log_format;
> +struct xfs_cil;
> +struct xfs_cil_ctx;
> struct xfs_bmbt_irec;
> struct xfs_btree_cur;
> struct xfs_refcount_irec;
> @@ -1112,6 +1114,53 @@
> DEFINE_AIL_EVENT(xfs_ail_move);
> DEFINE_AIL_EVENT(xfs_ail_delete);
>
> +DECLARE_EVENT_CLASS(xfs_cil_class,
> + TP_PROTO(struct xfs_cil *cil, struct xfs_cil_ctx *ctx),
> + TP_ARGS(cil, ctx),
> + TP_STRUCT__entry(
> + __field(struct xfs_cil *, cil)
> + __field(xfs_lsn_t, push_seq)
> + __field(xfs_lsn_t, curr_seq)
> + __field(xfs_lsn_t, chkpt_seq)
> + __field(xfs_lsn_t, start_lsn)
> + __field(xfs_lsn_t, commit_lsn)
> + __field(int, nvecs)
> + __field(int, space_used)
> + ),
> + TP_fast_assign(
> + __entry->cil = cil;
> + __entry->push_seq = cil->xc_push_seq;
> + __entry->curr_seq = cil->xc_current_sequence;
> + __entry->chkpt_seq = ctx->sequence;
> + __entry->start_lsn = ctx->start_lsn;
> + __entry->commit_lsn = ctx->commit_lsn;
> + __entry->nvecs = ctx->nvecs;
> + __entry->space_used = ctx->space_used;
> + ),
> + TP_printk("cil 0x%p push_seq %d/%d current_seq %d/%d chkpt_seq %d/%d "
> + "start_lsn %d/%d commit_lsn %d/%d nvecs %d space_used %d",
> + __entry->cil,
We need to print the "dev %d:%d" major/minor pair first so the
tracepoints can be correlated to a specific mount.
Brian
> + CYCLE_LSN(__entry->push_seq), BLOCK_LSN(__entry->push_seq),
> + CYCLE_LSN(__entry->curr_seq), BLOCK_LSN(__entry->curr_seq),
> + CYCLE_LSN(__entry->chkpt_seq), BLOCK_LSN(__entry->chkpt_seq),
> + CYCLE_LSN(__entry->start_lsn), BLOCK_LSN(__entry->start_lsn),
> + CYCLE_LSN(__entry->commit_lsn),
> + BLOCK_LSN(__entry->commit_lsn),
> + __entry->nvecs, __entry->space_used)
> +)
> +
> +#define DEFINE_CIL_EVENT(name) \
> +DEFINE_EVENT(xfs_cil_class, name, \
> + TP_PROTO(struct xfs_cil *cil, struct xfs_cil_ctx *ctx), \
> + TP_ARGS(cil, ctx))
> +DEFINE_CIL_EVENT(xlog_cil_push);
> +DEFINE_CIL_EVENT(xlog_cil_push_now);
> +DEFINE_CIL_EVENT(xlog_cil_push_background);
> +DEFINE_CIL_EVENT(xlog_cil_force_lsn);
> +DEFINE_CIL_EVENT(xlog_cil_force_lsn_exit);
> +DEFINE_CIL_EVENT(xlog_cil_committed);
> +DEFINE_CIL_EVENT(xfs_log_commit_cil);
> +
> TRACE_EVENT(xfs_log_assign_tail_lsn,
> TP_PROTO(struct xlog *log, xfs_lsn_t new_lsn),
> TP_ARGS(log, new_lsn),
> --
> 1.8.3.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2017-05-18 12:31 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-18 2:49 [PATCH 1/1] xfs: add trace points for xlog cil operations Shan Hai
2017-05-18 12:31 ` Brian Foster [this message]
2017-05-19 11:57 ` Shan Hai
2017-05-19 17:42 ` Brian Foster
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170518123156.GB18240@bfoster.bfoster \
--to=bfoster@redhat.com \
--cc=david@fromorbit.com \
--cc=linux-xfs@vger.kernel.org \
--cc=shan.hai@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.