linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@redhat.com>
To: Steve French <smfrench@gmail.com>
Cc: linux-cifs-client@lists.samba.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] cifs: implement drop_inode superblock op
Date: Tue, 25 May 2010 20:09:20 -0400	[thread overview]
Message-ID: <20100525200920.774cf77e@corrin.poochiereds.net> (raw)
In-Reply-To: <AANLkTik9uxiDI9RnpxTNTuv1RMz9pyms1hSapNP9Jk4p@mail.gmail.com>

On Tue, 25 May 2010 17:14:10 -0500
Steve French <smfrench@gmail.com> wrote:

> Any rough idea of performance or memory savings (even in something
> artificial like dbench run)?
> 

It's more of a memory savings thing. When I mount with -o noserverino
and run fsstress on the mount, I'd regularly see the size of the
cifs_inode_cache hit 60M or more (on a client with 1G RAM). With this
patch in place, it rarely goes over 2M in size.

Eventually, memory pressure will force the size to go down, but if we
know that they'll never be used again (which is the case with
noserverino), it's better to go ahead and just free them.

> On Tue, May 25, 2010 at 2:24 PM, Jeff Layton <jlayton@redhat.com> wrote:
> > The standard behavior for drop_inode is to delete the inode when the
> > last reference to it is put and the nlink count goes to 0. This helps
> > keep inodes that are still considered "not deleted" in cache as long as
> > possible even when there aren't dentries attached to them.
> >
> > When server inode numbers are disabled, it's not possible for cifs_iget
> > to ever match an existing inode (since inode numbers are generated via
> > iunique). In this situation, cifs can keep a lot of inodes in cache that
> > will never be used again.
> >
> > Implement a drop_inode routine that deletes the inode if server inode
> > numbers are disabled on the mount. This helps keep the cifs inode
> > caches down to a more manageable size when server inode numbers are
> > disabled.
> >
> > Signed-off-by: Jeff Layton <jlayton@redhat.com>
> > ---
> >  fs/cifs/cifsfs.c |   14 ++++++++++++--
> >  1 files changed, 12 insertions(+), 2 deletions(-)
> >
> > diff --git a/fs/cifs/cifsfs.c b/fs/cifs/cifsfs.c
> > index 78c02eb..8f647db 100644
> > --- a/fs/cifs/cifsfs.c
> > +++ b/fs/cifs/cifsfs.c
> > @@ -473,13 +473,23 @@ static int cifs_remount(struct super_block *sb, int *flags, char *data)
> >        return 0;
> >  }
> >
> > +void cifs_drop_inode(struct inode *inode)
> > +{
> > +       struct cifs_sb_info *cifs_sb = CIFS_SB(inode->i_sb);
> > +
> > +       if (cifs_sb->mnt_cifs_flags & CIFS_MOUNT_SERVER_INUM)
> > +               return generic_drop_inode(inode);
> > +
> > +       return generic_delete_inode(inode);
> > +}
> > +
> >  static const struct super_operations cifs_super_ops = {
> >        .put_super = cifs_put_super,
> >        .statfs = cifs_statfs,
> >        .alloc_inode = cifs_alloc_inode,
> >        .destroy_inode = cifs_destroy_inode,
> > -/*     .drop_inode         = generic_delete_inode,
> > -       .delete_inode   = cifs_delete_inode,  */  /* Do not need above two
> > +       .drop_inode     = cifs_drop_inode,
> > +/*     .delete_inode   = cifs_delete_inode,  */  /* Do not need above two
> >        functions unless later we add lazy close of inodes or unless the
> >        kernel forgets to call us with the same number of releases (closes)
> >        as opens */
> > --
> > 1.6.6.1
> >
> >
> 
> 
> 


-- 
Jeff Layton <jlayton@redhat.com>
--
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

  reply	other threads:[~2010-05-26  0:07 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-25 19:24 [PATCH] cifs: implement drop_inode superblock op Jeff Layton
2010-05-25 22:14 ` Steve French
2010-05-26  0:09   ` Jeff Layton [this message]
2010-05-26 23:19     ` [linux-cifs-client] " Scott Lovenberg
2010-05-27 13:38       ` Jeff Layton
2010-05-27 14:51         ` Steve French
2010-05-27 15:20           ` Jeff Layton
2010-05-26  2:16 ` Raja R Harinath

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=20100525200920.774cf77e@corrin.poochiereds.net \
    --to=jlayton@redhat.com \
    --cc=linux-cifs-client@lists.samba.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=smfrench@gmail.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).