From: Dave Chinner <david@fromorbit.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 03/14] xfs: convert log grant heads to LSN notation
Date: Thu, 2 Dec 2010 13:01:32 +1100 [thread overview]
Message-ID: <20101202020132.GP16922@dastard> (raw)
In-Reply-To: <20101201130504.GA18379@infradead.org>
On Wed, Dec 01, 2010 at 08:05:04AM -0500, Christoph Hellwig wrote:
> > -STATIC int xlog_space_left(xlog_t *log, int cycle, int bytes);
> > +STATIC int xlog_space_left(int logsize, xfs_lsn_t tail_lsn,
> > + xfs_lsn_t head);
>
> Looking further through the series I have to say I really hate
> passing in the logsize instead of the log structure. Passing the
> log pointer from higher level functions just makes a lot more sense.
>
> Also in this case passing the tail_lsn explicitly doesn't make any sense
> - it becomes atomic later and thus there is no locking requirement for
> it.
What I wanted to make clear is that the calculation works on fixed
values and doesn't sample values internally itself. I guess that's
not important for the log size, but for stuff like the tail lsn
it avoids needing to sample inside xlog_space_left() before we
crack it. i.e. something like this is wrong:
cycle = CYCLE_LSN(atomic64_read(&log->l_tail_lsn));
block = BLOCK_LSN(atomic64_read(&log->l_tail_lsn));
and this is correct:
tail_lsn = atomic64_read(&log->l_tail_lsn);
cycle = CYCLE_LSN(tail_lsn);
block = BLOCK_LSN(tail_lsn);
So it makes sense to me to have the value of of the tail lsn and
other variables that should only be sampled once passed into the
function. That avoids misunderstandings further down the track
because it is obvious that the calculation works on constant values.
Perhaps I should add "const" to the parameter declarations to help
make my intentions clear...
>
> > -xlog_grant_sub_space(struct log *log, int bytes)
> > +__xlog_grant_sub_space(
> > + xfs_lsn_t *head,
> > + int bytes,
> > + int logsize)
>
> Same thing here - the calling convention would be a lot more regular
> by still passing the log as first argument.
Ok, it's only for the logsize again, but that's not the important
part of the calculation...
> After the factoring I also think we could cut down on the amount of
> wrappers in this area. Just rename __xlog_grant_sub_space and
> __xlog_grant_add_space to not have the __ prefix, and kill the wrappers
> around it - they only have one or two callers, and just having two
> helpers and passing the heads we're interested in is a lot simpler and
> cleaner.
I thought about that - my first version even did this. I thought it
was easier to understand the changes if I didn't change the calling
conventions for modifying the grant heads. As such, I'd prefer to
make this change to the wrappers in a separate patch.
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-12-02 1:59 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-29 1:38 [PATCH 0/14] xfs: grant lock scaling and removal V2 Dave Chinner
2010-11-29 1:38 ` [PATCH 01/14] xfs: convert log grant ticket queues to list heads Dave Chinner
2010-11-30 22:59 ` Christoph Hellwig
2010-11-29 1:38 ` [PATCH 02/14] xfs: clean up log space grant functions Dave Chinner
2010-12-01 12:30 ` Christoph Hellwig
2010-12-02 1:48 ` Dave Chinner
2010-12-02 11:40 ` Christoph Hellwig
2010-12-03 6:45 ` Dave Chinner
2010-11-29 1:38 ` [PATCH 03/14] xfs: convert log grant heads to LSN notation Dave Chinner
2010-12-01 12:42 ` Christoph Hellwig
2010-12-02 1:49 ` Dave Chinner
2010-12-01 13:05 ` Christoph Hellwig
2010-12-02 2:01 ` Dave Chinner [this message]
2010-12-02 11:47 ` Christoph Hellwig
2010-11-29 1:38 ` [PATCH 04/14] xfs: use wait queues directly for log grant queues Dave Chinner
2010-12-01 12:34 ` Christoph Hellwig
2010-12-02 2:02 ` Dave Chinner
2010-11-29 1:38 ` [PATCH 05/14] xfs: make AIL tail pushing independent of the grant lock Dave Chinner
2010-12-01 12:45 ` Christoph Hellwig
2010-12-02 2:04 ` Dave Chinner
2010-11-29 1:38 ` [PATCH 06/14] xfs: convert l_last_sync_lsn to an atomic variable Dave Chinner
2010-12-01 12:54 ` Christoph Hellwig
2010-11-29 1:38 ` [PATCH 07/14] xfs: convert l_tail_lsn " Dave Chinner
2010-12-01 12:56 ` Christoph Hellwig
2010-11-29 1:38 ` [PATCH 08/14] xfs: convert log grant heads to atomic variables Dave Chinner
2010-12-01 12:59 ` Christoph Hellwig
2010-12-02 2:04 ` Dave Chinner
2010-11-29 1:38 ` [PATCH 09/14] xfs: introduce new locks for the log grant ticket wait queues Dave Chinner
2010-12-01 13:12 ` Christoph Hellwig
2010-12-02 2:10 ` Dave Chinner
2010-12-02 11:48 ` Christoph Hellwig
2010-11-29 1:38 ` [PATCH 10/14] xfs: convert grant head manipulations to lockless algorithm Dave Chinner
2010-12-01 13:15 ` Christoph Hellwig
2010-12-02 2:11 ` Dave Chinner
2010-11-29 1:38 ` [PATCH 11/14] xfs: remove log grant lock Dave Chinner
2010-12-01 13:15 ` Christoph Hellwig
2010-11-29 1:38 ` [PATCH 12/14] xfs: kill useless spinlock_destroy macro Dave Chinner
2010-12-01 13:19 ` Christoph Hellwig
2010-11-29 1:38 ` [PATCH 13/14] xfs: replace use of sv_t with waitqueues in the log Dave Chinner
2010-12-01 13:20 ` Christoph Hellwig
2010-11-29 1:38 ` [PATCH 14/14] xfs: remove sv wrappers Dave Chinner
2010-12-01 13:20 ` Christoph Hellwig
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=20101202020132.GP16922@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