From: Christoph Hellwig <hch@infradead.org>
To: Dave Chinner <david@fromorbit.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 1/9] xfs: struct xfs_buf_log_format isn't variable sized.
Date: Tue, 26 Jun 2012 06:14:11 -0400 [thread overview]
Message-ID: <20120626101411.GA26241@infradead.org> (raw)
In-Reply-To: <1340355015-26250-2-git-send-email-david@fromorbit.com>
On Fri, Jun 22, 2012 at 06:50:07PM +1000, Dave Chinner wrote:
> From: Dave Chinner <dchinner@redhat.com>
>
> The struct xfs_buf_log_format wants to think the dirty bitmap is
> variable sized. In fact, it is variable size on disk simply due to
> the way we map it from the in-memory structure, but we still just
> use a fixed size memory allocation for the in-memory structure.
>
> Hence it makes no sense to set the function up as a variable sized
> structure when we already know it's maximum size, and we always
> allocate it as such. Simplify the structure by making the dirty
> bitmap a fixed sized array and just using the size of the structure
> for the allocation size.
>
> This will make it much simpler to allocate and manipulate an array
> of format structures for discontiguous buffer support.
>
> The previous struct xfs_buf_log_item size according to
> /proc/slabinfo was 224 bytes. pahole doesn't give the same size
> because of the variable size definition. With this modification,
> pahole reports the same as /proc/slabinfo:
>
> /* size: 224, cachelines: 4, members: 6 */
>
> Because the xfs_buf_log_item size is now determined by the maximum
> supported block size we introduce a dependency on xfs_alloc_btree.h.
> Avoid this dependency by moving the idefines for the maximum block
> sizes supported to xfs_types.h with all the other max/min type
> defines to avoid any new dependencies.
>
> Signed-off-by: Dave Chinner <dchinner@redhat.com>
Looks good,
Reviewed-by: Christoph Hellwig <hch@lst.de>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2012-06-26 10:14 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-22 8:50 [PATCH 0/9, V2] xfs; discontiguous buffer support Dave Chinner
2012-06-22 8:50 ` [PATCH 1/9] xfs: struct xfs_buf_log_format isn't variable sized Dave Chinner
2012-06-26 10:14 ` Christoph Hellwig [this message]
2012-06-22 8:50 ` [PATCH 2/9] xfs: separate buffer indexing from block map Dave Chinner
2012-06-26 10:14 ` Christoph Hellwig
2012-06-22 8:50 ` [PATCH 3/9] xfs: convert internal buffer functions to pass maps Dave Chinner
2012-06-26 10:15 ` Christoph Hellwig
2012-06-22 8:50 ` [PATCH 4/9] xfs: add discontiguous buffer map interface Dave Chinner
2012-06-22 8:50 ` [PATCH 5/9] xfs: add discontiguous buffer support to transactions Dave Chinner
2012-06-22 8:50 ` [PATCH 6/9] xfs: support discontiguous buffers in the xfs_buf_log_item Dave Chinner
2012-06-22 8:50 ` [PATCH 7/9] xfs: use discontiguous xfs_buf support in dabuf wrappers Dave Chinner
2012-06-22 8:50 ` [PATCH 8/9] xfs: remove struct xfs_dabuf and infrastructure Dave Chinner
2012-06-22 8:50 ` [PATCH 9/9] xfs: factor buffer reading from xfs_dir2_leaf_getdents Dave Chinner
2012-06-26 10:16 ` 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=20120626101411.GA26241@infradead.org \
--to=hch@infradead.org \
--cc=david@fromorbit.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.