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
next prev parent 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 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.