reiserfs-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Andreas Dilger <adilger@dilger.ca>
Cc: Dave Kleikamp <shaggy@kernel.org>,
	jfs-discussion@lists.sourceforge.net, Jan Kara <jack@suse.cz>,
	Jeff Mahoney <jeffm@suse.de>, Mark Fasheh <mfasheh@suse.com>,
	reiserfs-devel@vger.kernel.org, xfs@oss.sgi.com,
	cluster-devel@redhat.com, Joel Becker <jlbec@evilplan.org>,
	linux-fsdevel@vger.kernel.org, tytso@mit.edu,
	linux-ext4@vger.kernel.org,
	Steven Whitehouse <swhiteho@redhat.com>,
	ocfs2-devel@oss.oracle.com
Subject: Re: [PATCH 04/12] fs: Generic infrastructure for optional inode fields
Date: Wed, 8 Oct 2014 10:45:09 +0200	[thread overview]
Message-ID: <20141008084509.GC11781@quack.suse.cz> (raw)
In-Reply-To: <3BFF1023-E198-4797-A96A-EA158137157E@dilger.ca>

On Wed 01-10-14 15:05:46, Andreas Dilger wrote:
> On Oct 1, 2014, at 1:31 PM, Jan Kara <jack@suse.cz> wrote:
> > There are parts of struct inode which are used only by a few filesystems
> > (e.g. i_dquot pointers, i_mapping->private_list, ...). Thus all the
> > other filesystems are just wasting memory with these fields. On the
> > other hand it isn't simple to just move these fields to filesystem
> > specific part of inode because there is generic code which needs to peek
> > into the fields and it is cumbersome to provide helpers into which fs
> > has to stuff the field it is storing elsewhere.
> > 
> > We create a simple infrastructure which allows for optional inode fields
> > stored in the fs-specific part of the inode. Accessing these fields has
> > a slightly worse performance as we have to lookup their offset in the
> > offset table stored in the superblock but in most cases this is
> > acceptable. Notably, this offset-table mechanism is faster than having
> > fs-specific hook functions which would need to be called to provide
> > pointers to desired fields.
> > 
> > Signed-off-by: Jan Kara <jack@suse.cz>
> > ---
> > include/linux/fs.h | 24 ++++++++++++++++++++++++
> > 1 file changed, 24 insertions(+)
> > 
> > diff --git a/include/linux/fs.h b/include/linux/fs.h
> > index 94187721ad41..977f8fb6ca88 100644
> > --- a/include/linux/fs.h
> > +++ b/include/linux/fs.h
> > @@ -615,6 +615,11 @@ struct inode {
> > 	void			*i_private; /* fs or device private pointer */
> > };
> > 
> > +/* Optional inode fields (stored in filesystems inode if the fs needs them) */
> > +enum {
> 
> This should be a named enum, like "enum inode_field" or similar, so it
> can be referenced below.
> 
> > +	IF_FIELD_NR	/* Number of optional inode fields */
> > +};
> > +
> > static inline int inode_unhashed(struct inode *inode)
> > {
> > 	return hlist_unhashed(&inode->i_hash);
> > @@ -1236,6 +1241,11 @@ struct super_block {
> > 	void 			*s_fs_info;	/* Filesystem private info */
> > 	unsigned int		s_max_links;
> > 	fmode_t			s_mode;
> > +	/*
> > +	 * We could have here just a pointer to the offsets array but this
> > +	 * way we save one dereference when looking up field offsets
> > +	 */
> > +	int			s_inode_fields[IF_FIELD_NR];
> > 
> > 	/* Granularity of c/m/atime in ns.
> > 	   Cannot be worse than a second */
> > @@ -1286,6 +1296,20 @@ struct super_block {
> > 	struct rcu_head		rcu;
> > };
> > 
> > +static inline void *inode_field(const struct inode *inode, int field)
> 
> This should use "enum inode_field" instead of int, so the compiler could
> warn about invalid parameter values.  It might make sense to add a check:
  OK, makes sense.

>         if (field < IF_FIELD_NR)
> 
> but I'm not sure if the overhead is worthwhile, unless it can always be
> resolved at compile time.  That might be possible since this is a static
> inline function.
  Well, I can stick there BUG_ON(field >= IF_FIELD_NR). That looks like a
sensible debugging measure with negligible overhead.

								Honza
> > +{
> > +	int offset = inode->i_sb->s_inode_fields[field];
> > +
> > +	if (!offset)	/* Field not present? */
> > +		return NULL;
> 
> > +	return ((char *)inode) + offset;
> > +}
> > +
> > +static inline void sb_init_inode_fields(struct super_block *sb, int *fields)
> > +{
> > +	memcpy(sb->s_inode_fields, fields, sizeof(int) * IF_FIELD_NR);
> > +}
> > +
> > extern struct timespec current_fs_time(struct super_block *sb);
> > 
> > /*
> > -- 
> > 1.8.1.4
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> Cheers, Andreas
> 
> 
> 
> 
> 


-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

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

  reply	other threads:[~2014-10-08  8:45 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-01 19:31 [PATCH 0/12 RFC] Moving i_dquot out of struct inode Jan Kara
2014-10-01 19:31 ` [PATCH 01/12] quota: Allow each filesystem to specify which quota types it supports Jan Kara
2014-10-01 19:31 ` [PATCH 02/12] gfs2: Set allowed quota types Jan Kara
2014-10-02 10:41   ` Steven Whitehouse
2014-10-01 19:31 ` [PATCH 03/12] xfs: " Jan Kara
2014-10-06 20:30   ` Dave Chinner
2014-10-07 19:29     ` Jan Kara
2014-10-07 19:46       ` Andreas Dilger
2014-10-08  8:42         ` Jan Kara
2014-10-01 19:31 ` [PATCH 04/12] fs: Generic infrastructure for optional inode fields Jan Kara
2014-10-01 21:05   ` Andreas Dilger
2014-10-08  8:45     ` Jan Kara [this message]
2014-10-01 19:31 ` [PATCH 05/12] quota: Use optional inode field for i_dquot pointers Jan Kara
2014-10-01 19:31 ` [PATCH 06/12] ext2: Convert to private i_dquot field Jan Kara
2014-10-01 19:31 ` [PATCH 07/12] ext3: " Jan Kara
2014-10-01 19:31 ` [PATCH 08/12] ext4: " Jan Kara
2014-10-01 19:31 ` [PATCH 09/12] ocfs2: " Jan Kara
2014-10-01 19:31 ` [PATCH 10/12] reiserfs: " Jan Kara
2014-10-01 19:31 ` [PATCH 11/12] jfs: " Jan Kara
2014-10-01 19:31 ` [PATCH 12/12] vfs: Remove i_dquot field from inode Jan Kara
  -- strict thread matches above, loose matches on Subject: below --
2014-10-10 14:54 [PATCH 0/12 v2] Moving i_dquot out of struct inode Jan Kara
2014-10-10 14:55 ` [PATCH 04/12] fs: Generic infrastructure for optional inode fields Jan Kara

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=20141008084509.GC11781@quack.suse.cz \
    --to=jack@suse.cz \
    --cc=adilger@dilger.ca \
    --cc=cluster-devel@redhat.com \
    --cc=jeffm@suse.de \
    --cc=jfs-discussion@lists.sourceforge.net \
    --cc=jlbec@evilplan.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=mfasheh@suse.com \
    --cc=ocfs2-devel@oss.oracle.com \
    --cc=reiserfs-devel@vger.kernel.org \
    --cc=shaggy@kernel.org \
    --cc=swhiteho@redhat.com \
    --cc=tytso@mit.edu \
    --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;
as well as URLs for NNTP newsgroup(s).