All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: xfs@oss.sgi.com
Subject: Re: [RFC PATCH 0/8] xfs: shrink the struct xfs_icdinode
Date: Wed, 13 Jan 2016 08:05:17 +1100	[thread overview]
Message-ID: <20160112210517.GK10456@dastard> (raw)
In-Reply-To: <20160112153010.GA29662@infradead.org>

On Tue, Jan 12, 2016 at 07:30:10AM -0800, Christoph Hellwig wrote:
> Nice!
> 
> I had started on some of this a while ago but never finished it..

*nod*

> > 72 bytes. This means it takes 104 bytes off the size of the struct
> > xfs_inode, which a 12% reduction in size. This will be a massive win
> > for systems that cache lots of inodes!
> 
> How many more inodes can we fit into a slab cache now?  Back when I
> started I noticed it doesn't help us to actually fit more inodes into
> a 4k page due to the bloated VFS inode.  But these days slub actually
> uses a high order allocations if I remember correctly so it might be
> more useful.

On a debug build (because that's the only numbers I have at hand),
the current code is 1280 bytes/inode, 25 inodes/slab, 8 pages/slab.
This patch set makes it 1152 bytes/inode, 28 inodes/slab, 8
pages/slab, so that's a 12% increase in the number of cached inodes
for a given amount of slab memory.

IIRC, a production build is around 960 bytes/inode, so that would
put it at 34 inodes/slab for the current code and 38 inodes/slab
for the current patchset. That, again, is roughly 12% increase in
inodes per slab....

> > With this change made, the xfs_icdinode is no long an "in core disk
> > inode" so I'm wondering whether I should rename it or simply make it
> > go away altogether and pull the remaining fields straight into the
> > struct xfs_inode. Any thoughts on new names and/or getting rid of it
> > woul dbe appreciated.
> 
> I think it should be merged into the xfs_inode structure soner or
> later.

Ok, I'll look at doing that.

> Another thign I planned but never got to is to move fields
> into the inode fork that were specific to the attr or data fork.

That's a whole different problem ;)

Cheers,

Dave.


-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

      reply	other threads:[~2016-01-12 21:07 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-12  9:01 [RFC PATCH 0/8] xfs: shrink the struct xfs_icdinode Dave Chinner
2016-01-12  9:01 ` [PATCH 1/8] xfs: introduce inode log format object Dave Chinner
2016-01-12  9:01 ` [PATCH 2/8] xfs: remove timestamps from incore inode Dave Chinner
2016-01-12  9:01 ` [PATCH 3/8] xfs; cull unnecessary icdinode fields Dave Chinner
2016-01-12  9:01 ` [PATCH 4/8] xfs: move v1 inode conversion to xfs_inode_from_disk Dave Chinner
2016-01-12  9:01 ` [PATCH 5/8] xfs: use vfs inode nlink field everywhere Dave Chinner
2016-01-12  9:01 ` [PATCH 6/8] xfs: move inode generation count to VFS inode Dave Chinner
2016-01-12  9:01 ` [PATCH 7/8] xfs: move di_changecount " Dave Chinner
2016-01-12  9:01 ` [PATCH 8/8] xfs: mode di_mode to vfs inode Dave Chinner
2016-01-12 15:30 ` [RFC PATCH 0/8] xfs: shrink the struct xfs_icdinode Christoph Hellwig
2016-01-12 21:05   ` Dave Chinner [this message]

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=20160112210517.GK10456@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.