linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Shan Hai <shan.hai@oracle.com>
To: Brian Foster <bfoster@redhat.com>
Cc: linux-xfs@vger.kernel.org, david@fromorbit.com
Subject: Re: [PATCH 1/1] xfs: add trace points for xlog cil operations
Date: Fri, 19 May 2017 19:57:38 +0800	[thread overview]
Message-ID: <df9a5c6e-6d6f-571e-8464-58a2596e4008@oracle.com> (raw)
In-Reply-To: <20170518123156.GB18240@bfoster.bfoster>



On 2017年05月18日 20:31, Brian Foster wrote:
> 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 ;).

Sorry for the late reply.

The reason why I try to add the trace points is that when I was running
fs_mark to stress the xfs log operations by small files I found out
that the files/sec statistic drops from thousands to hundreds in certain
point of time, the reason for this is probably that the ail/cil is pushing
at the same time since the log is full and the new transactions are
waiting for the log space to be freed.

I was hoping that tracing the cil would probably provide information for
further analyzing the issue.

I agree with your opinions on the patch, and how about just tracing
the _push_cil to get start/commit lsn of the checkpoint transaction?

I have tried to push the cil in 5 seconds intervals and push ail to
ctx->commit_lsn at the end of cil_committed but it didn't help much,
but I am still trying :)

Thanks
Shan Hai
>> I  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
> --
> 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


  reply	other threads:[~2017-05-19 11:57 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
2017-05-19 11:57   ` Shan Hai [this message]
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=df9a5c6e-6d6f-571e-8464-58a2596e4008@oracle.com \
    --to=shan.hai@oracle.com \
    --cc=bfoster@redhat.com \
    --cc=david@fromorbit.com \
    --cc=linux-xfs@vger.kernel.org \
    /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 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).