lkml.org 
[lkml]   [2009]   [Apr]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch 01/27] fs: cleanup files_lock
On Fri, Apr 24, 2009 at 10:35:10PM -0700, Eric W. Biederman wrote:
> npiggin@suse.de writes:
>
> > Lock tty_files with tty_mutex, provide helpers to manipulate the per-sb
> > files list, and unexport the files_lock spinlock.
>
> This conflicts a bit with some of my ongoing work, which is generalizing
> the file list to make it more useful and makes the tty case much less
> of a special case.

OK. My first patch should be fine, though.


> Do you know if the performance improvement would be anywhere near as good if
> file_list and file_list_lock becoming per inode?

Interesting (I didn't look closely at your patches yet). Probably that
would be quite reasonable.


> Do you have any idea what the performance improvement with changing the file_list_lock
> is?

Several of these locks hit in the same workloads so they mask each
other. I only just got the patchset to the stage where I can really
benchmark it. I could try your alternative as well.



> > Index: linux-2.6/fs/open.c
> > ===================================================================
> > --- linux-2.6.orig/fs/open.c
> > +++ linux-2.6/fs/open.c
> > @@ -828,7 +828,7 @@ static struct file *__dentry_open(struct
> > f->f_path.mnt = mnt;
> > f->f_pos = 0;
> > f->f_op = fops_get(inode->i_fop);
> > - file_move(f, &inode->i_sb->s_files);
> > + file_sb_list_add(f, inode->i_sb);
>
> You can make this just:
> if (!special_file(inode->i_mode))
> file_add(f, &inode->i_files);
>
> And save yourself a lot of complexity.

Probably right, but I'll leave that for someone else to do.



\
 
 \ /
  Last update: 2009-04-26 08:15    [W:0.147 / U:43.452 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site