public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 09/12] xfs: Introduce delayed logging core code
Date: Mon, 10 May 2010 22:16:28 +1000	[thread overview]
Message-ID: <20100510121628.GD7165@dastard> (raw)
In-Reply-To: <20100510114435.GA27624@infradead.org>

On Mon, May 10, 2010 at 07:44:35AM -0400, Christoph Hellwig wrote:
> Looks good to me,
> 
> 
> Reviewed-by: Christoph Hellwig <hch@lst.de>
> 
> A couple comments below anyway:
> 
> > +int
> > +xlog_cil_init_post_recovery(
> > +	struct log	*log)
> > +{
> > +	if (!log->l_cilp)
> > +		return 0;
> > +
> > +	log->l_cilp->xc_ctx->ticket = xlog_cil_ticket_alloc(log);
> > +	log->l_cilp->xc_ctx->sequence = 1;
> > +	log->l_cilp->xc_ctx->commit_lsn = xlog_assign_lsn(log->l_curr_cycle,
> > +								log->l_curr_block);
> > +	return 0;
> > +}
> 
> This should return void.

OK.

> > +static void
> > +xlog_cil_insert(
> > +	struct log		*log,
> > +	struct xlog_ticket	*ticket,
> > +	struct xfs_log_item	*item,
> > +	struct xfs_log_vec	*lv)
> > +{
> > +	struct xfs_cil		*cil = log->l_cilp;
> > +	struct xfs_log_vec *old = lv->lv_item->li_lv;
> > +	struct xfs_cil_ctx *ctx = cil->xc_ctx;
> > +	int		len;
> > +	int		diff_iovecs;
> > +	int		iclog_space;
> > +
> > +	if (old) {
> > +		/* existing lv on log item, space used is a delta */
> > +		ASSERT(!list_empty(&item->li_cil));
> > +		ASSERT(old->lv_buf && old->lv_buf_len && old->lv_niovecs);
> > +
> > +		len = lv->lv_buf_len - old->lv_buf_len;
> > +		diff_iovecs = lv->lv_niovecs - old->lv_niovecs;
> 
> Add asserts that len and diff_iovecs aren't negative here?

Actually, they can be negative here - a previously logged buffer
that is now stale will go from ((N dirty regions * 128 bytes) +
format header) to (zero dirty regions + format header), and
effectively free up space as what was previously logged is now
ignored due to the XFS_BLI_CANCEL flag in the format header.

> > +	for (lv = log_vector; lv; lv = lv->lv_next) {
> > +		void	*ptr;
> > +		int	index;
> > +		int	offset = 0;
> > +		int	len = 0;
> > +
> > +		for (index = 0; index < lv->lv_niovecs; index++)
> > +			len += lv->lv_iovecp[index].i_len;
> > +
> > +		lv->lv_buf_len = len;
> > +		lv->lv_buf = kmem_zalloc(lv->lv_buf_len, KM_SLEEP|KM_NOFS);
> > +		ptr = lv->lv_buf;
> > +
> > +		for (index = 0; index < lv->lv_niovecs; index++) {
> > +			struct xfs_log_iovec *vec = &lv->lv_iovecp[index];
> > +
> > +			memcpy(ptr, vec->i_addr, vec->i_len);
> > +			vec->i_addr = ptr;
> > +			xlog_write_adv_cnt(&ptr, &len, &offset, vec->i_len);
> > +		}
> > +		ASSERT(len == 0);
> > +
> > +		xlog_cil_insert(log, ticket, lv->lv_item, lv);
> 
> The use of xlog_write_adv_cnt doesn't seem quite optimal to me.  The
> offset variable is entirely unused, and len is only used for an asswer
> that could easily be reformulated as
> 
> 	ASSERT(ptr == lv->lv_buf + len);
> 
> if we replace the xlog_write_adv_cnt with a simple
> 
> 	ptr += vec->i_len;

Good idea - xlog_write_adv_cnt() was left over from the original
code that was copied from the log code.

> 
> > +/*
> > + * Push the Committed Item List to the log. If the push_now flag is not set,
> > + * then it is a background flush and so we can chose to ignore it.
> > + */
> > +int
> > +xlog_cil_push(
> > +	struct log	*log,
> > +	int		push_now)
> > +{
> > +	struct xfs_cil		*cil = log->l_cilp;
> 
> The variables don't line up here.  There's another instance of that
> in xlog_cil_insert, btw.

Ok, will fix.

> 
> > +	/* check if we've anything to push */
> > +	if (list_empty(&cil->xc_cil)) {
> > +		up_write(&cil->xc_ctx_lock);
> > +		xfs_log_ticket_put(new_ctx->ticket);
> > +		kmem_free(new_ctx);
> > +		return 0;
> > +	}
> 
> Please add a out_skip label for this cleanup code, as it would be
> duplicated by the background flushing check added in a later patch.

OK.

> > +		new_lv = kmem_zalloc(sizeof(*new_lv) +
> > +				lidp->lid_size * sizeof(struct xfs_log_iovec),
> > +				KM_SLEEP);
> > +
> > +		/* The allocated iovec region lies beyond the log vector. */
> > +		new_lv->lv_iovecp = (struct xfs_log_iovec *)&new_lv[1];
> > +		if (!ret_lv)
> > +			ret_lv = new_lv;
> > +		else
> > +			lv->lv_next = new_lv;
> > +		lv = new_lv;
> 
> I'd suggest already setting up lv->lv_niovecs and lv->lv_item here
> instead of in xfs_trans_fill_log_vecs.  That way xfs_trans_fill_log_vecs
> can be simplified to:
> 
> STATIC void
> xfs_trans_fill_log_vecs(
> 	struct xfs_trans	*tp,
> 	struct xfs_log_vec	*log_vector)
> {
> 	struct xfs_log_vec	*lv;
> 
> 	for (lv = log_vector; lv = lv->lv_next; lv)
> 		IOP_FORMAT(lidp->lid_item, lv->lv_iovecp);
> }
> 
> Or just inlined into the caller or even xfs_log_commit_cil given how simple
> it is now.  Moving it to xfs_log_commit_cil would also help avoiding the
> locking imbalance where xfs_log_commit_cil is called with xc_ctx_lock
> held but returns without it after the last patch in the series.  That
> again might allow merging the IOP_FORMAT loop into xlog_cil_format_items.
> 
> Btw, I wonder if xfs_log_commit_cil should simply move to xfs_trans.c?
> That would avoid having to export xfs_trans_unreserve_and_mod_sb,
> xfs_trans_free_items and xfs_trans_free from there, and only require
> exporting xlog_cil_format_items (if we didn't move that one as well,
> then xlog_cil_insert), while keeping things a lot more symmetric with
> the traditional commit path.

I did find it a bit hard trying to draw the line between the trans
subsystem and the logging subsystem because of the interactions and
the way they changed as I developed the code and fixed bugs. I'll
have a closer look at what you are suggesting (it seems reasonable
just from a quick scan) and see how much it cleans up.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2010-05-10 12:14 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-07  5:40 [PATCH 0/12] xfs: delayed logging V5 Dave Chinner
2010-05-07  5:40 ` [PATCH 01/12] xfs: Don't reuse the same transaction ID for duplicated transactions Dave Chinner
2010-05-07  5:40 ` [PATCH 02/12] xfs: allow log ticket allocation to take allocation flags Dave Chinner
2010-05-07  5:40 ` [PATCH 03/12] xfs: modify buffer item reference counting Dave Chinner
2010-05-07  5:40 ` [PATCH 04/12] xfs: Clean up XFS_BLI_* flag namespace Dave Chinner
2010-05-07  5:40 ` [PATCH 05/12] xfs: clean up log ticket overrun debug output Dave Chinner
2010-05-07  5:40 ` [PATCH 06/12] xfs: make the log ticket ID available outside the log infrastructure Dave Chinner
2010-05-07 11:41   ` Christoph Hellwig
2010-05-07  5:40 ` [PATCH 07/12] xfs: Improve scalability of busy extent tracking Dave Chinner
2010-05-08 17:15   ` Christoph Hellwig
2010-05-07  5:40 ` [PATCH 08/12] xfs: Delayed logging design documentation Dave Chinner
2010-05-07  5:40 ` [PATCH 09/12] xfs: Introduce delayed logging core code Dave Chinner
2010-05-10 11:44   ` Christoph Hellwig
2010-05-10 12:16     ` Dave Chinner [this message]
2010-05-17  5:51       ` Dave Chinner
2010-05-17  7:34         ` Christoph Hellwig
2010-05-07  5:40 ` [PATCH 10/12] xfs: forced unmounts need to push the CIL Dave Chinner
2010-05-10 11:44   ` Christoph Hellwig
2010-05-07  5:40 ` [PATCH 11/12] xfs: enable background pushing of " Dave Chinner
2010-05-10 11:45   ` Christoph Hellwig
2010-05-07  5:41 ` [PATCH 12/12] xfs: Ensure inode allocation buffers are fully replayed Dave Chinner
2010-05-10 17:43   ` Christoph Hellwig
  -- strict thread matches above, loose matches on Subject: below --
2010-05-17 23:24 [PATCH 0/12] xfs: delayed logging V6 Dave Chinner
2010-05-17 23:24 ` [PATCH 09/12] xfs: Introduce delayed logging core code Dave Chinner
2010-05-21 21:06   ` Alex Elder

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=20100510121628.GD7165@dastard \
    --to=david@fromorbit.com \
    --cc=hch@infradead.org \
    --cc=xfs@oss.sgi.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox