[Top] [All Lists]

Re: [PATCH 46/49] xfs: Combine CIL insert and prepare passes

To: Mark Tinguely <tinguely@xxxxxxx>
Subject: Re: [PATCH 46/49] xfs: Combine CIL insert and prepare passes
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Thu, 25 Jul 2013 10:23:30 +1000
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <51EEF3D4.2000201@xxxxxxx>
References: <1374215120-7271-1-git-send-email-david@xxxxxxxxxxxxx> <1374215120-7271-47-git-send-email-david@xxxxxxxxxxxxx> <51EEF3D4.2000201@xxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Tue, Jul 23, 2013 at 04:21:24PM -0500, Mark Tinguely wrote:
> On 07/19/13 01:25, Dave Chinner wrote:
> >From: Dave Chinner<dchinner@xxxxxxxxxx>
> >
> >Now that all the log item preparation and formatting is done under
> >the CIL lock, we can get rid of the intermediate log vector chain
> >used to track items to be inserted into the CIL.
> >
> >We can already find all the items to be committed from the
> >transaction handle, so as long as we attach the log vectors to the
> >item before we insert the items into the CIL, we don't need to
> >create a log vector chain to pass around.
> >
> >This means we can move all the item insertion code into and optimise
> >it into a pair of simple passes across all the items in the
> >transaction. The first pass does the formatting and accounting, the
> >second inserts them all into the CIL.
> >
> >We keep this two pass split so that we can separate the CIL
> >insertion - which must be done under the CIL spinlock - from the
> >formatting. We could insert each item into the CIL with a single
> >pass, but that massively increases the number of times we have to
> >grab the CIL spinlock. It is much more efficient (and hence
> >scalable) to do a batch operation and insert all objects in a single
> >lock grab.
> >
> >Signed-off-by: Dave Chinner<dchinner@xxxxxxxxxx>
> ...
> >@@ -357,10 +341,8 @@ xlog_cil_insert_items(
> >      * during the transaction commit.
> >      */
> >     if (ctx->ticket->t_curr_res == 0) {
> >-            /* first commit in checkpoint, steal the header reservation */
> >-            ASSERT(ticket->t_curr_res>= ctx->ticket->t_unit_res + len);
> ^^ is the ctx ticket overflow caught somewhere else? ^^^^

Of course. It's caught in same check that catches all other
transaction overruns - in the caller after this function returns.
And it prints the ticket now, too, which means it's a far more
functional check that the current one...


Dave Chinner

<Prev in Thread] Current Thread [Next in Thread>