From: Timothy Shimmin <tes@sgi.com>
To: David Chinner <dgc@sgi.com>
Cc: xfs-dev <xfs-dev@sgi.com>, xfs-oss <xfs@oss.sgi.com>
Subject: Re: [patch] Prevent AIL lock contention during transaction completion
Date: Fri, 25 Jan 2008 17:51:33 +1100 [thread overview]
Message-ID: <479986F5.7070800@sgi.com> (raw)
In-Reply-To: <20080123073446.GU155259@sgi.com>
David Chinner & Tim wrote:
>> And xfs_log_move_tail is called by:
>> * xfs_trans_update_ail, xfs_trans_delete_ail,
>> (xfs_trans_unlocked_item and xlog_ungrant_log_space who call
>> xfs_log_move_tail call it with param 1 which doesn't modify
>> l_tail_lsn)
>> I would have thought update_ail and delete_ail would cover the
>> changes to the ail and hence what the new min item in the ail list
>> is and hence the change in the tail.
>
> Right - the tail gets moved by (re)moving the tail object in the AIL
>
>> In the case of an empty AIL, I guess it needs to use l_last_sync_lsn
>> which is what xlog_assign_tail_lsn gives you that xfs_log_move_tail
>> doesn't.
>
> No, if a value of zero is passed to xfs_log_move_tail(), the lsn is
> grabbed from l_last_sync_lsn, so when we remove the last object from
> the AIL from xfs_trans_delete_ail() we set the l_tail_lsn to l_last_sync_lsn,
> same as xlog_assign_tail_lsn does.
>
Yep, sorry missed that bit (we do the same in both).
> IOWs, xlog_assign_tail_lsn() could really be considered redundant as
> the I/O completion keeps the l_tail_lsn up to date via the AIL manipulation
> functions. I decided to split the difference and ensure that what is
> written to the iclog does not change by calling it just before the
> tail lsn is written into the header....
>
> IOWs, I don't think calling xlog_assign_tail_lsn() in
> xlog_state_release_iclog() ever changes the l_tail_lsn because
> it is always kept up to date via the notifications in the AIL
> code.....
>
Exactly.
When looking, I just couldn't see what calling xlog_assign_tail_lsn() is
going to do for us considering every time we change the AIL (from
metadata io completions etc) we update the l_tail_lsn immediately.
Which led me to look at what differences there could be (and found
a wrong difference ;-).
So do we really need to call xlog_assign_tail_lsn() then?
Or are we just being conservative in case we missed something?
--Tim
next prev parent reply other threads:[~2008-01-25 6:50 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-21 5:23 [patch] Prevent AIL lock contention during transaction completion David Chinner
2008-01-23 7:12 ` Timothy Shimmin
2008-01-23 7:34 ` David Chinner
2008-01-25 6:51 ` Timothy Shimmin [this message]
2008-01-25 7:42 ` David Chinner
2008-02-14 23:45 ` David Chinner
2008-02-14 23:52 ` Timothy Shimmin
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=479986F5.7070800@sgi.com \
--to=tes@sgi.com \
--cc=dgc@sgi.com \
--cc=xfs-dev@sgi.com \
--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.