2005-04-16 16:20:36 -06:00
|
|
|
/*
|
|
|
|
* linux/fs/file_table.c
|
|
|
|
*
|
|
|
|
* Copyright (C) 1991, 1992 Linus Torvalds
|
|
|
|
* Copyright (C) 1997 David S. Miller (davem@caip.rutgers.edu)
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/string.h>
|
|
|
|
#include <linux/slab.h>
|
|
|
|
#include <linux/file.h>
|
2008-04-24 05:44:08 -06:00
|
|
|
#include <linux/fdtable.h>
|
2005-04-16 16:20:36 -06:00
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/fs.h>
|
|
|
|
#include <linux/security.h>
|
|
|
|
#include <linux/eventpoll.h>
|
2005-09-09 14:04:13 -06:00
|
|
|
#include <linux/rcupdate.h>
|
2005-04-16 16:20:36 -06:00
|
|
|
#include <linux/mount.h>
|
2006-01-11 13:17:46 -07:00
|
|
|
#include <linux/capability.h>
|
2005-04-16 16:20:36 -06:00
|
|
|
#include <linux/cdev.h>
|
[PATCH] inotify
inotify is intended to correct the deficiencies of dnotify, particularly
its inability to scale and its terrible user interface:
* dnotify requires the opening of one fd per each directory
that you intend to watch. This quickly results in too many
open files and pins removable media, preventing unmount.
* dnotify is directory-based. You only learn about changes to
directories. Sure, a change to a file in a directory affects
the directory, but you are then forced to keep a cache of
stat structures.
* dnotify's interface to user-space is awful. Signals?
inotify provides a more usable, simple, powerful solution to file change
notification:
* inotify's interface is a system call that returns a fd, not SIGIO.
You get a single fd, which is select()-able.
* inotify has an event that says "the filesystem that the item
you were watching is on was unmounted."
* inotify can watch directories or files.
Inotify is currently used by Beagle (a desktop search infrastructure),
Gamin (a FAM replacement), and other projects.
See Documentation/filesystems/inotify.txt.
Signed-off-by: Robert Love <rml@novell.com>
Cc: John McCutchan <ttb@tentacle.dhs.org>
Cc: Christoph Hellwig <hch@lst.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-12 15:06:03 -06:00
|
|
|
#include <linux/fsnotify.h>
|
2006-03-07 22:55:35 -07:00
|
|
|
#include <linux/sysctl.h>
|
fs: scale files_lock
fs: scale files_lock
Improve scalability of files_lock by adding per-cpu, per-sb files lists,
protected with an lglock. The lglock provides fast access to the per-cpu lists
to add and remove files. It also provides a snapshot of all the per-cpu lists
(although this is very slow).
One difficulty with this approach is that a file can be removed from the list
by another CPU. We must track which per-cpu list the file is on with a new
variale in the file struct (packed into a hole on 64-bit archs). Scalability
could suffer if files are frequently removed from different cpu's list.
However loads with frequent removal of files imply short interval between
adding and removing the files, and the scheduler attempts to avoid moving
processes too far away. Also, even in the case of cross-CPU removal, the
hardware has much more opportunity to parallelise cacheline transfers with N
cachelines than with 1.
A worst-case test of 1 CPU allocating files subsequently being freed by N CPUs
degenerates to contending on a single lock, which is no worse than before. When
more than one CPU are allocating files, even if they are always freed by
different CPUs, there will be more parallelism than the single-lock case.
Testing results:
On a 2 socket, 8 core opteron, I measure the number of times the lock is taken
to remove the file, the number of times it is removed by the same CPU that
added it, and the number of times it is removed by the same node that added it.
Booting: locks= 25049 cpu-hits= 23174 (92.5%) node-hits= 23945 (95.6%)
kbuild -j16 locks=2281913 cpu-hits=2208126 (96.8%) node-hits=2252674 (98.7%)
dbench 64 locks=4306582 cpu-hits=4287247 (99.6%) node-hits=4299527 (99.8%)
So a file is removed from the same CPU it was added by over 90% of the time.
It remains within the same node 95% of the time.
Tim Chen ran some numbers for a 64 thread Nehalem system performing a compile.
throughput
2.6.34-rc2 24.5
+patch 24.9
us sys idle IO wait (in %)
2.6.34-rc2 51.25 28.25 17.25 3.25
+patch 53.75 18.5 19 8.75
So significantly less CPU time spent in kernel code, higher idle time and
slightly higher throughput.
Single threaded performance difference was within the noise of microbenchmarks.
That is not to say penalty does not exist, the code is larger and more memory
accesses required so it will be slightly slower.
Cc: linux-kernel@vger.kernel.org
Cc: Tim Chen <tim.c.chen@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Nick Piggin <npiggin@kernel.dk>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2010-08-17 12:37:38 -06:00
|
|
|
#include <linux/lglock.h>
|
2006-03-07 22:55:35 -07:00
|
|
|
#include <linux/percpu_counter.h>
|
fs: scale files_lock
fs: scale files_lock
Improve scalability of files_lock by adding per-cpu, per-sb files lists,
protected with an lglock. The lglock provides fast access to the per-cpu lists
to add and remove files. It also provides a snapshot of all the per-cpu lists
(although this is very slow).
One difficulty with this approach is that a file can be removed from the list
by another CPU. We must track which per-cpu list the file is on with a new
variale in the file struct (packed into a hole on 64-bit archs). Scalability
could suffer if files are frequently removed from different cpu's list.
However loads with frequent removal of files imply short interval between
adding and removing the files, and the scheduler attempts to avoid moving
processes too far away. Also, even in the case of cross-CPU removal, the
hardware has much more opportunity to parallelise cacheline transfers with N
cachelines than with 1.
A worst-case test of 1 CPU allocating files subsequently being freed by N CPUs
degenerates to contending on a single lock, which is no worse than before. When
more than one CPU are allocating files, even if they are always freed by
different CPUs, there will be more parallelism than the single-lock case.
Testing results:
On a 2 socket, 8 core opteron, I measure the number of times the lock is taken
to remove the file, the number of times it is removed by the same CPU that
added it, and the number of times it is removed by the same node that added it.
Booting: locks= 25049 cpu-hits= 23174 (92.5%) node-hits= 23945 (95.6%)
kbuild -j16 locks=2281913 cpu-hits=2208126 (96.8%) node-hits=2252674 (98.7%)
dbench 64 locks=4306582 cpu-hits=4287247 (99.6%) node-hits=4299527 (99.8%)
So a file is removed from the same CPU it was added by over 90% of the time.
It remains within the same node 95% of the time.
Tim Chen ran some numbers for a 64 thread Nehalem system performing a compile.
throughput
2.6.34-rc2 24.5
+patch 24.9
us sys idle IO wait (in %)
2.6.34-rc2 51.25 28.25 17.25 3.25
+patch 53.75 18.5 19 8.75
So significantly less CPU time spent in kernel code, higher idle time and
slightly higher throughput.
Single threaded performance difference was within the noise of microbenchmarks.
That is not to say penalty does not exist, the code is larger and more memory
accesses required so it will be slightly slower.
Cc: linux-kernel@vger.kernel.org
Cc: Tim Chen <tim.c.chen@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Nick Piggin <npiggin@kernel.dk>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2010-08-17 12:37:38 -06:00
|
|
|
#include <linux/percpu.h>
|
2009-12-16 02:53:03 -07:00
|
|
|
#include <linux/ima.h>
|
2006-03-07 22:55:35 -07:00
|
|
|
|
|
|
|
#include <asm/atomic.h>
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2009-12-04 13:47:36 -07:00
|
|
|
#include "internal.h"
|
|
|
|
|
2005-04-16 16:20:36 -06:00
|
|
|
/* sysctl tunables... */
|
|
|
|
struct files_stat_struct files_stat = {
|
|
|
|
.max_files = NR_FILE
|
|
|
|
};
|
|
|
|
|
fs: scale files_lock
fs: scale files_lock
Improve scalability of files_lock by adding per-cpu, per-sb files lists,
protected with an lglock. The lglock provides fast access to the per-cpu lists
to add and remove files. It also provides a snapshot of all the per-cpu lists
(although this is very slow).
One difficulty with this approach is that a file can be removed from the list
by another CPU. We must track which per-cpu list the file is on with a new
variale in the file struct (packed into a hole on 64-bit archs). Scalability
could suffer if files are frequently removed from different cpu's list.
However loads with frequent removal of files imply short interval between
adding and removing the files, and the scheduler attempts to avoid moving
processes too far away. Also, even in the case of cross-CPU removal, the
hardware has much more opportunity to parallelise cacheline transfers with N
cachelines than with 1.
A worst-case test of 1 CPU allocating files subsequently being freed by N CPUs
degenerates to contending on a single lock, which is no worse than before. When
more than one CPU are allocating files, even if they are always freed by
different CPUs, there will be more parallelism than the single-lock case.
Testing results:
On a 2 socket, 8 core opteron, I measure the number of times the lock is taken
to remove the file, the number of times it is removed by the same CPU that
added it, and the number of times it is removed by the same node that added it.
Booting: locks= 25049 cpu-hits= 23174 (92.5%) node-hits= 23945 (95.6%)
kbuild -j16 locks=2281913 cpu-hits=2208126 (96.8%) node-hits=2252674 (98.7%)
dbench 64 locks=4306582 cpu-hits=4287247 (99.6%) node-hits=4299527 (99.8%)
So a file is removed from the same CPU it was added by over 90% of the time.
It remains within the same node 95% of the time.
Tim Chen ran some numbers for a 64 thread Nehalem system performing a compile.
throughput
2.6.34-rc2 24.5
+patch 24.9
us sys idle IO wait (in %)
2.6.34-rc2 51.25 28.25 17.25 3.25
+patch 53.75 18.5 19 8.75
So significantly less CPU time spent in kernel code, higher idle time and
slightly higher throughput.
Single threaded performance difference was within the noise of microbenchmarks.
That is not to say penalty does not exist, the code is larger and more memory
accesses required so it will be slightly slower.
Cc: linux-kernel@vger.kernel.org
Cc: Tim Chen <tim.c.chen@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Nick Piggin <npiggin@kernel.dk>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2010-08-17 12:37:38 -06:00
|
|
|
DECLARE_LGLOCK(files_lglock);
|
|
|
|
DEFINE_LGLOCK(files_lglock);
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2008-12-10 10:35:45 -07:00
|
|
|
/* SLAB cache for file structures */
|
|
|
|
static struct kmem_cache *filp_cachep __read_mostly;
|
|
|
|
|
2006-03-07 22:55:35 -07:00
|
|
|
static struct percpu_counter nr_files __cacheline_aligned_in_smp;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2006-03-07 22:55:35 -07:00
|
|
|
static inline void file_free_rcu(struct rcu_head *head)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
2008-11-13 16:39:25 -07:00
|
|
|
struct file *f = container_of(head, struct file, f_u.fu_rcuhead);
|
|
|
|
|
|
|
|
put_cred(f->f_cred);
|
2006-03-07 22:55:35 -07:00
|
|
|
kmem_cache_free(filp_cachep, f);
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
|
2006-03-07 22:55:35 -07:00
|
|
|
static inline void file_free(struct file *f)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
2006-03-07 22:55:35 -07:00
|
|
|
percpu_counter_dec(&nr_files);
|
2008-02-15 15:38:01 -07:00
|
|
|
file_check_state(f);
|
2006-03-07 22:55:35 -07:00
|
|
|
call_rcu(&f->f_u.fu_rcuhead, file_free_rcu);
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
|
2006-03-07 22:55:35 -07:00
|
|
|
/*
|
|
|
|
* Return the total number of open files in the system
|
|
|
|
*/
|
2010-10-26 15:22:44 -06:00
|
|
|
static long get_nr_files(void)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
2006-03-07 22:55:35 -07:00
|
|
|
return percpu_counter_read_positive(&nr_files);
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
|
2006-03-07 22:55:35 -07:00
|
|
|
/*
|
|
|
|
* Return the maximum number of open files in the system
|
|
|
|
*/
|
2010-10-26 15:22:44 -06:00
|
|
|
unsigned long get_max_files(void)
|
2005-09-09 14:04:13 -06:00
|
|
|
{
|
2006-03-07 22:55:35 -07:00
|
|
|
return files_stat.max_files;
|
2005-09-09 14:04:13 -06:00
|
|
|
}
|
2006-03-07 22:55:35 -07:00
|
|
|
EXPORT_SYMBOL_GPL(get_max_files);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Handle nr_files sysctl
|
|
|
|
*/
|
|
|
|
#if defined(CONFIG_SYSCTL) && defined(CONFIG_PROC_FS)
|
2009-09-23 16:57:19 -06:00
|
|
|
int proc_nr_files(ctl_table *table, int write,
|
2006-03-07 22:55:35 -07:00
|
|
|
void __user *buffer, size_t *lenp, loff_t *ppos)
|
|
|
|
{
|
|
|
|
files_stat.nr_files = get_nr_files();
|
2010-10-26 15:22:44 -06:00
|
|
|
return proc_doulongvec_minmax(table, write, buffer, lenp, ppos);
|
2006-03-07 22:55:35 -07:00
|
|
|
}
|
|
|
|
#else
|
2009-09-23 16:57:19 -06:00
|
|
|
int proc_nr_files(ctl_table *table, int write,
|
2006-03-07 22:55:35 -07:00
|
|
|
void __user *buffer, size_t *lenp, loff_t *ppos)
|
|
|
|
{
|
|
|
|
return -ENOSYS;
|
|
|
|
}
|
|
|
|
#endif
|
2005-09-09 14:04:13 -06:00
|
|
|
|
2005-04-16 16:20:36 -06:00
|
|
|
/* Find an unused file structure and return a pointer to it.
|
|
|
|
* Returns NULL, if there are no more free file structures or
|
|
|
|
* we run out of memory.
|
2008-02-15 15:37:26 -07:00
|
|
|
*
|
|
|
|
* Be very careful using this. You are responsible for
|
|
|
|
* getting write access to any mount that you might assign
|
|
|
|
* to this filp, if it is opened for write. If this is not
|
|
|
|
* done, you will imbalance int the mount's writer count
|
|
|
|
* and a warning at __fput() time.
|
2005-04-16 16:20:36 -06:00
|
|
|
*/
|
|
|
|
struct file *get_empty_filp(void)
|
|
|
|
{
|
2008-11-13 16:39:18 -07:00
|
|
|
const struct cred *cred = current_cred();
|
2010-10-26 15:22:44 -06:00
|
|
|
static long old_max;
|
2005-04-16 16:20:36 -06:00
|
|
|
struct file * f;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Privileged users can go above max_files
|
|
|
|
*/
|
2006-03-07 22:55:35 -07:00
|
|
|
if (get_nr_files() >= files_stat.max_files && !capable(CAP_SYS_ADMIN)) {
|
|
|
|
/*
|
|
|
|
* percpu_counters are inaccurate. Do an expensive check before
|
|
|
|
* we go and fail.
|
|
|
|
*/
|
2007-10-17 00:25:44 -06:00
|
|
|
if (percpu_counter_sum_positive(&nr_files) >= files_stat.max_files)
|
2006-03-07 22:55:35 -07:00
|
|
|
goto over;
|
|
|
|
}
|
2005-06-23 01:09:50 -06:00
|
|
|
|
2007-10-17 00:26:19 -06:00
|
|
|
f = kmem_cache_zalloc(filp_cachep, GFP_KERNEL);
|
2005-06-23 01:09:50 -06:00
|
|
|
if (f == NULL)
|
|
|
|
goto fail;
|
|
|
|
|
2006-03-07 22:55:35 -07:00
|
|
|
percpu_counter_inc(&nr_files);
|
2005-06-23 01:09:50 -06:00
|
|
|
if (security_file_alloc(f))
|
|
|
|
goto fail_sec;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2006-03-23 04:01:03 -07:00
|
|
|
INIT_LIST_HEAD(&f->f_u.fu_list);
|
2008-07-25 22:39:17 -06:00
|
|
|
atomic_long_set(&f->f_count, 1);
|
2005-06-23 01:09:50 -06:00
|
|
|
rwlock_init(&f->f_owner.lock);
|
2008-11-13 16:39:25 -07:00
|
|
|
f->f_cred = get_cred(cred);
|
2009-02-06 13:52:43 -07:00
|
|
|
spin_lock_init(&f->f_lock);
|
2006-03-23 04:01:03 -07:00
|
|
|
eventpoll_init_file(f);
|
2005-06-23 01:09:50 -06:00
|
|
|
/* f->f_version: 0 */
|
|
|
|
return f;
|
|
|
|
|
|
|
|
over:
|
2005-04-16 16:20:36 -06:00
|
|
|
/* Ran out of filps - report that */
|
2006-03-07 22:55:35 -07:00
|
|
|
if (get_nr_files() > old_max) {
|
2010-10-26 15:22:44 -06:00
|
|
|
pr_info("VFS: file-max limit %lu reached\n", get_max_files());
|
2006-03-07 22:55:35 -07:00
|
|
|
old_max = get_nr_files();
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
2005-06-23 01:09:50 -06:00
|
|
|
goto fail;
|
|
|
|
|
|
|
|
fail_sec:
|
|
|
|
file_free(f);
|
2005-04-16 16:20:36 -06:00
|
|
|
fail:
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2007-10-17 00:31:13 -06:00
|
|
|
/**
|
|
|
|
* alloc_file - allocate and initialize a 'struct file'
|
|
|
|
* @mnt: the vfsmount on which the file will reside
|
|
|
|
* @dentry: the dentry representing the new file
|
|
|
|
* @mode: the mode with which the new file will be opened
|
|
|
|
* @fop: the 'struct file_operations' for the new file
|
|
|
|
*
|
|
|
|
* Use this instead of get_empty_filp() to get a new
|
|
|
|
* 'struct file'. Do so because of the same initialization
|
|
|
|
* pitfalls reasons listed for init_file(). This is a
|
|
|
|
* preferred interface to using init_file().
|
|
|
|
*
|
|
|
|
* If all the callers of init_file() are eliminated, its
|
|
|
|
* code should be moved into this function.
|
|
|
|
*/
|
2009-08-08 14:52:35 -06:00
|
|
|
struct file *alloc_file(struct path *path, fmode_t mode,
|
|
|
|
const struct file_operations *fop)
|
2007-10-17 00:31:13 -06:00
|
|
|
{
|
|
|
|
struct file *file;
|
|
|
|
|
|
|
|
file = get_empty_filp();
|
|
|
|
if (!file)
|
|
|
|
return NULL;
|
|
|
|
|
2009-08-08 14:52:35 -06:00
|
|
|
file->f_path = *path;
|
|
|
|
file->f_mapping = path->dentry->d_inode->i_mapping;
|
2007-10-17 00:31:13 -06:00
|
|
|
file->f_mode = mode;
|
|
|
|
file->f_op = fop;
|
2008-02-15 15:37:48 -07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* These mounts don't really matter in practice
|
|
|
|
* for r/o bind mounts. They aren't userspace-
|
|
|
|
* visible. We do this for consistency, and so
|
|
|
|
* that we can do debugging checks at __fput()
|
|
|
|
*/
|
2009-08-08 14:52:35 -06:00
|
|
|
if ((mode & FMODE_WRITE) && !special_file(path->dentry->d_inode->i_mode)) {
|
2008-02-15 15:38:01 -07:00
|
|
|
file_take_write(file);
|
2009-12-16 13:48:44 -07:00
|
|
|
WARN_ON(mnt_clone_write(path->mnt));
|
2008-02-15 15:37:48 -07:00
|
|
|
}
|
2009-12-16 02:53:03 -07:00
|
|
|
ima_counts_get(file);
|
2009-08-08 13:56:29 -06:00
|
|
|
return file;
|
2007-10-17 00:31:13 -06:00
|
|
|
}
|
2009-12-16 13:43:11 -07:00
|
|
|
EXPORT_SYMBOL(alloc_file);
|
2007-10-17 00:31:13 -06:00
|
|
|
|
2008-02-15 15:37:31 -07:00
|
|
|
/**
|
|
|
|
* drop_file_write_access - give up ability to write to a file
|
|
|
|
* @file: the file to which we will stop writing
|
|
|
|
*
|
|
|
|
* This is a central place which will give up the ability
|
|
|
|
* to write to @file, along with access to write through
|
|
|
|
* its vfsmount.
|
|
|
|
*/
|
|
|
|
void drop_file_write_access(struct file *file)
|
|
|
|
{
|
2008-02-15 15:37:48 -07:00
|
|
|
struct vfsmount *mnt = file->f_path.mnt;
|
2008-02-15 15:37:31 -07:00
|
|
|
struct dentry *dentry = file->f_path.dentry;
|
|
|
|
struct inode *inode = dentry->d_inode;
|
|
|
|
|
|
|
|
put_write_access(inode);
|
2008-02-15 15:38:01 -07:00
|
|
|
|
|
|
|
if (special_file(inode->i_mode))
|
|
|
|
return;
|
|
|
|
if (file_check_writeable(file) != 0)
|
|
|
|
return;
|
|
|
|
mnt_drop_write(mnt);
|
|
|
|
file_release_write(file);
|
2008-02-15 15:37:31 -07:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(drop_file_write_access);
|
|
|
|
|
2010-05-26 13:13:55 -06:00
|
|
|
/* the real guts of fput() - releasing the last reference to file
|
2005-04-16 16:20:36 -06:00
|
|
|
*/
|
2010-05-26 13:13:55 -06:00
|
|
|
static void __fput(struct file *file)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
2006-12-08 03:36:35 -07:00
|
|
|
struct dentry *dentry = file->f_path.dentry;
|
|
|
|
struct vfsmount *mnt = file->f_path.mnt;
|
2005-04-16 16:20:36 -06:00
|
|
|
struct inode *inode = dentry->d_inode;
|
|
|
|
|
|
|
|
might_sleep();
|
[PATCH] inotify
inotify is intended to correct the deficiencies of dnotify, particularly
its inability to scale and its terrible user interface:
* dnotify requires the opening of one fd per each directory
that you intend to watch. This quickly results in too many
open files and pins removable media, preventing unmount.
* dnotify is directory-based. You only learn about changes to
directories. Sure, a change to a file in a directory affects
the directory, but you are then forced to keep a cache of
stat structures.
* dnotify's interface to user-space is awful. Signals?
inotify provides a more usable, simple, powerful solution to file change
notification:
* inotify's interface is a system call that returns a fd, not SIGIO.
You get a single fd, which is select()-able.
* inotify has an event that says "the filesystem that the item
you were watching is on was unmounted."
* inotify can watch directories or files.
Inotify is currently used by Beagle (a desktop search infrastructure),
Gamin (a FAM replacement), and other projects.
See Documentation/filesystems/inotify.txt.
Signed-off-by: Robert Love <rml@novell.com>
Cc: John McCutchan <ttb@tentacle.dhs.org>
Cc: Christoph Hellwig <hch@lst.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-12 15:06:03 -06:00
|
|
|
|
|
|
|
fsnotify_close(file);
|
2005-04-16 16:20:36 -06:00
|
|
|
/*
|
|
|
|
* The function eventpoll_release() should be the first called
|
|
|
|
* in the file cleanup chain.
|
|
|
|
*/
|
|
|
|
eventpoll_release(file);
|
|
|
|
locks_remove_flock(file);
|
|
|
|
|
2008-10-31 17:28:30 -06:00
|
|
|
if (unlikely(file->f_flags & FASYNC)) {
|
|
|
|
if (file->f_op && file->f_op->fasync)
|
|
|
|
file->f_op->fasync(-1, file, 0);
|
|
|
|
}
|
2005-04-16 16:20:36 -06:00
|
|
|
if (file->f_op && file->f_op->release)
|
|
|
|
file->f_op->release(inode, file);
|
|
|
|
security_file_free(file);
|
2010-02-07 01:07:29 -07:00
|
|
|
ima_file_free(file);
|
2006-09-27 02:50:49 -06:00
|
|
|
if (unlikely(S_ISCHR(inode->i_mode) && inode->i_cdev != NULL))
|
2005-04-16 16:20:36 -06:00
|
|
|
cdev_put(inode->i_cdev);
|
|
|
|
fops_put(file->f_op);
|
2006-10-02 03:17:15 -06:00
|
|
|
put_pid(file->f_owner.pid);
|
2010-08-17 12:37:35 -06:00
|
|
|
file_sb_list_del(file);
|
2008-02-15 15:37:31 -07:00
|
|
|
if (file->f_mode & FMODE_WRITE)
|
|
|
|
drop_file_write_access(file);
|
2006-12-08 03:36:35 -07:00
|
|
|
file->f_path.dentry = NULL;
|
|
|
|
file->f_path.mnt = NULL;
|
2005-04-16 16:20:36 -06:00
|
|
|
file_free(file);
|
|
|
|
dput(dentry);
|
|
|
|
mntput(mnt);
|
|
|
|
}
|
|
|
|
|
2010-05-26 13:13:55 -06:00
|
|
|
void fput(struct file *file)
|
|
|
|
{
|
|
|
|
if (atomic_long_dec_and_test(&file->f_count))
|
|
|
|
__fput(file);
|
|
|
|
}
|
|
|
|
|
|
|
|
EXPORT_SYMBOL(fput);
|
|
|
|
|
2008-02-08 05:19:52 -07:00
|
|
|
struct file *fget(unsigned int fd)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
|
|
|
struct file *file;
|
|
|
|
struct files_struct *files = current->files;
|
|
|
|
|
2005-09-09 14:04:13 -06:00
|
|
|
rcu_read_lock();
|
2005-04-16 16:20:36 -06:00
|
|
|
file = fcheck_files(files, fd);
|
2005-09-09 14:04:13 -06:00
|
|
|
if (file) {
|
2008-07-25 22:39:17 -06:00
|
|
|
if (!atomic_long_inc_not_zero(&file->f_count)) {
|
2005-09-09 14:04:13 -06:00
|
|
|
/* File object ref couldn't be taken */
|
|
|
|
rcu_read_unlock();
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
rcu_read_unlock();
|
|
|
|
|
2005-04-16 16:20:36 -06:00
|
|
|
return file;
|
|
|
|
}
|
|
|
|
|
|
|
|
EXPORT_SYMBOL(fget);
|
|
|
|
|
|
|
|
/*
|
2010-08-10 19:01:29 -06:00
|
|
|
* Lightweight file lookup - no refcnt increment if fd table isn't shared.
|
|
|
|
*
|
|
|
|
* You can use this instead of fget if you satisfy all of the following
|
|
|
|
* conditions:
|
|
|
|
* 1) You must call fput_light before exiting the syscall and returning control
|
|
|
|
* to userspace (i.e. you cannot remember the returned struct file * after
|
|
|
|
* returning to userspace).
|
|
|
|
* 2) You must not call filp_close on the returned struct file * in between
|
|
|
|
* calls to fget_light and fput_light.
|
|
|
|
* 3) You must not clone the current task in between the calls to fget_light
|
|
|
|
* and fput_light.
|
|
|
|
*
|
|
|
|
* The fput_needed flag returned by fget_light should be passed to the
|
|
|
|
* corresponding fput_light.
|
2005-04-16 16:20:36 -06:00
|
|
|
*/
|
2008-02-08 05:19:52 -07:00
|
|
|
struct file *fget_light(unsigned int fd, int *fput_needed)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
|
|
|
struct file *file;
|
|
|
|
struct files_struct *files = current->files;
|
|
|
|
|
|
|
|
*fput_needed = 0;
|
2010-12-13 17:38:09 -07:00
|
|
|
if (atomic_read(&files->count) == 1) {
|
2005-04-16 16:20:36 -06:00
|
|
|
file = fcheck_files(files, fd);
|
|
|
|
} else {
|
2005-09-09 14:04:13 -06:00
|
|
|
rcu_read_lock();
|
2005-04-16 16:20:36 -06:00
|
|
|
file = fcheck_files(files, fd);
|
|
|
|
if (file) {
|
2008-07-25 22:39:17 -06:00
|
|
|
if (atomic_long_inc_not_zero(&file->f_count))
|
2005-09-09 14:04:13 -06:00
|
|
|
*fput_needed = 1;
|
|
|
|
else
|
|
|
|
/* Didn't get the reference, someone's freed */
|
|
|
|
file = NULL;
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
2005-09-09 14:04:13 -06:00
|
|
|
rcu_read_unlock();
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
2005-09-09 14:04:13 -06:00
|
|
|
|
2005-04-16 16:20:36 -06:00
|
|
|
return file;
|
|
|
|
}
|
|
|
|
|
|
|
|
void put_filp(struct file *file)
|
|
|
|
{
|
2008-07-25 22:39:17 -06:00
|
|
|
if (atomic_long_dec_and_test(&file->f_count)) {
|
2005-04-16 16:20:36 -06:00
|
|
|
security_file_free(file);
|
2010-08-17 12:37:35 -06:00
|
|
|
file_sb_list_del(file);
|
2005-04-16 16:20:36 -06:00
|
|
|
file_free(file);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
fs: scale files_lock
fs: scale files_lock
Improve scalability of files_lock by adding per-cpu, per-sb files lists,
protected with an lglock. The lglock provides fast access to the per-cpu lists
to add and remove files. It also provides a snapshot of all the per-cpu lists
(although this is very slow).
One difficulty with this approach is that a file can be removed from the list
by another CPU. We must track which per-cpu list the file is on with a new
variale in the file struct (packed into a hole on 64-bit archs). Scalability
could suffer if files are frequently removed from different cpu's list.
However loads with frequent removal of files imply short interval between
adding and removing the files, and the scheduler attempts to avoid moving
processes too far away. Also, even in the case of cross-CPU removal, the
hardware has much more opportunity to parallelise cacheline transfers with N
cachelines than with 1.
A worst-case test of 1 CPU allocating files subsequently being freed by N CPUs
degenerates to contending on a single lock, which is no worse than before. When
more than one CPU are allocating files, even if they are always freed by
different CPUs, there will be more parallelism than the single-lock case.
Testing results:
On a 2 socket, 8 core opteron, I measure the number of times the lock is taken
to remove the file, the number of times it is removed by the same CPU that
added it, and the number of times it is removed by the same node that added it.
Booting: locks= 25049 cpu-hits= 23174 (92.5%) node-hits= 23945 (95.6%)
kbuild -j16 locks=2281913 cpu-hits=2208126 (96.8%) node-hits=2252674 (98.7%)
dbench 64 locks=4306582 cpu-hits=4287247 (99.6%) node-hits=4299527 (99.8%)
So a file is removed from the same CPU it was added by over 90% of the time.
It remains within the same node 95% of the time.
Tim Chen ran some numbers for a 64 thread Nehalem system performing a compile.
throughput
2.6.34-rc2 24.5
+patch 24.9
us sys idle IO wait (in %)
2.6.34-rc2 51.25 28.25 17.25 3.25
+patch 53.75 18.5 19 8.75
So significantly less CPU time spent in kernel code, higher idle time and
slightly higher throughput.
Single threaded performance difference was within the noise of microbenchmarks.
That is not to say penalty does not exist, the code is larger and more memory
accesses required so it will be slightly slower.
Cc: linux-kernel@vger.kernel.org
Cc: Tim Chen <tim.c.chen@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Nick Piggin <npiggin@kernel.dk>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2010-08-17 12:37:38 -06:00
|
|
|
static inline int file_list_cpu(struct file *file)
|
|
|
|
{
|
|
|
|
#ifdef CONFIG_SMP
|
|
|
|
return file->f_sb_list_cpu;
|
|
|
|
#else
|
|
|
|
return smp_processor_id();
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
|
|
|
/* helper for file_sb_list_add to reduce ifdefs */
|
|
|
|
static inline void __file_sb_list_add(struct file *file, struct super_block *sb)
|
|
|
|
{
|
|
|
|
struct list_head *list;
|
|
|
|
#ifdef CONFIG_SMP
|
|
|
|
int cpu;
|
|
|
|
cpu = smp_processor_id();
|
|
|
|
file->f_sb_list_cpu = cpu;
|
|
|
|
list = per_cpu_ptr(sb->s_files, cpu);
|
|
|
|
#else
|
|
|
|
list = &sb->s_files;
|
|
|
|
#endif
|
|
|
|
list_add(&file->f_u.fu_list, list);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* file_sb_list_add - add a file to the sb's file list
|
|
|
|
* @file: file to add
|
|
|
|
* @sb: sb to add it to
|
|
|
|
*
|
|
|
|
* Use this function to associate a file with the superblock of the inode it
|
|
|
|
* refers to.
|
|
|
|
*/
|
2010-08-17 12:37:35 -06:00
|
|
|
void file_sb_list_add(struct file *file, struct super_block *sb)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
fs: scale files_lock
fs: scale files_lock
Improve scalability of files_lock by adding per-cpu, per-sb files lists,
protected with an lglock. The lglock provides fast access to the per-cpu lists
to add and remove files. It also provides a snapshot of all the per-cpu lists
(although this is very slow).
One difficulty with this approach is that a file can be removed from the list
by another CPU. We must track which per-cpu list the file is on with a new
variale in the file struct (packed into a hole on 64-bit archs). Scalability
could suffer if files are frequently removed from different cpu's list.
However loads with frequent removal of files imply short interval between
adding and removing the files, and the scheduler attempts to avoid moving
processes too far away. Also, even in the case of cross-CPU removal, the
hardware has much more opportunity to parallelise cacheline transfers with N
cachelines than with 1.
A worst-case test of 1 CPU allocating files subsequently being freed by N CPUs
degenerates to contending on a single lock, which is no worse than before. When
more than one CPU are allocating files, even if they are always freed by
different CPUs, there will be more parallelism than the single-lock case.
Testing results:
On a 2 socket, 8 core opteron, I measure the number of times the lock is taken
to remove the file, the number of times it is removed by the same CPU that
added it, and the number of times it is removed by the same node that added it.
Booting: locks= 25049 cpu-hits= 23174 (92.5%) node-hits= 23945 (95.6%)
kbuild -j16 locks=2281913 cpu-hits=2208126 (96.8%) node-hits=2252674 (98.7%)
dbench 64 locks=4306582 cpu-hits=4287247 (99.6%) node-hits=4299527 (99.8%)
So a file is removed from the same CPU it was added by over 90% of the time.
It remains within the same node 95% of the time.
Tim Chen ran some numbers for a 64 thread Nehalem system performing a compile.
throughput
2.6.34-rc2 24.5
+patch 24.9
us sys idle IO wait (in %)
2.6.34-rc2 51.25 28.25 17.25 3.25
+patch 53.75 18.5 19 8.75
So significantly less CPU time spent in kernel code, higher idle time and
slightly higher throughput.
Single threaded performance difference was within the noise of microbenchmarks.
That is not to say penalty does not exist, the code is larger and more memory
accesses required so it will be slightly slower.
Cc: linux-kernel@vger.kernel.org
Cc: Tim Chen <tim.c.chen@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Nick Piggin <npiggin@kernel.dk>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2010-08-17 12:37:38 -06:00
|
|
|
lg_local_lock(files_lglock);
|
|
|
|
__file_sb_list_add(file, sb);
|
|
|
|
lg_local_unlock(files_lglock);
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
|
fs: scale files_lock
fs: scale files_lock
Improve scalability of files_lock by adding per-cpu, per-sb files lists,
protected with an lglock. The lglock provides fast access to the per-cpu lists
to add and remove files. It also provides a snapshot of all the per-cpu lists
(although this is very slow).
One difficulty with this approach is that a file can be removed from the list
by another CPU. We must track which per-cpu list the file is on with a new
variale in the file struct (packed into a hole on 64-bit archs). Scalability
could suffer if files are frequently removed from different cpu's list.
However loads with frequent removal of files imply short interval between
adding and removing the files, and the scheduler attempts to avoid moving
processes too far away. Also, even in the case of cross-CPU removal, the
hardware has much more opportunity to parallelise cacheline transfers with N
cachelines than with 1.
A worst-case test of 1 CPU allocating files subsequently being freed by N CPUs
degenerates to contending on a single lock, which is no worse than before. When
more than one CPU are allocating files, even if they are always freed by
different CPUs, there will be more parallelism than the single-lock case.
Testing results:
On a 2 socket, 8 core opteron, I measure the number of times the lock is taken
to remove the file, the number of times it is removed by the same CPU that
added it, and the number of times it is removed by the same node that added it.
Booting: locks= 25049 cpu-hits= 23174 (92.5%) node-hits= 23945 (95.6%)
kbuild -j16 locks=2281913 cpu-hits=2208126 (96.8%) node-hits=2252674 (98.7%)
dbench 64 locks=4306582 cpu-hits=4287247 (99.6%) node-hits=4299527 (99.8%)
So a file is removed from the same CPU it was added by over 90% of the time.
It remains within the same node 95% of the time.
Tim Chen ran some numbers for a 64 thread Nehalem system performing a compile.
throughput
2.6.34-rc2 24.5
+patch 24.9
us sys idle IO wait (in %)
2.6.34-rc2 51.25 28.25 17.25 3.25
+patch 53.75 18.5 19 8.75
So significantly less CPU time spent in kernel code, higher idle time and
slightly higher throughput.
Single threaded performance difference was within the noise of microbenchmarks.
That is not to say penalty does not exist, the code is larger and more memory
accesses required so it will be slightly slower.
Cc: linux-kernel@vger.kernel.org
Cc: Tim Chen <tim.c.chen@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Nick Piggin <npiggin@kernel.dk>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2010-08-17 12:37:38 -06:00
|
|
|
/**
|
|
|
|
* file_sb_list_del - remove a file from the sb's file list
|
|
|
|
* @file: file to remove
|
|
|
|
* @sb: sb to remove it from
|
|
|
|
*
|
|
|
|
* Use this function to remove a file from its superblock.
|
|
|
|
*/
|
2010-08-17 12:37:35 -06:00
|
|
|
void file_sb_list_del(struct file *file)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
2005-10-30 16:02:16 -07:00
|
|
|
if (!list_empty(&file->f_u.fu_list)) {
|
fs: scale files_lock
fs: scale files_lock
Improve scalability of files_lock by adding per-cpu, per-sb files lists,
protected with an lglock. The lglock provides fast access to the per-cpu lists
to add and remove files. It also provides a snapshot of all the per-cpu lists
(although this is very slow).
One difficulty with this approach is that a file can be removed from the list
by another CPU. We must track which per-cpu list the file is on with a new
variale in the file struct (packed into a hole on 64-bit archs). Scalability
could suffer if files are frequently removed from different cpu's list.
However loads with frequent removal of files imply short interval between
adding and removing the files, and the scheduler attempts to avoid moving
processes too far away. Also, even in the case of cross-CPU removal, the
hardware has much more opportunity to parallelise cacheline transfers with N
cachelines than with 1.
A worst-case test of 1 CPU allocating files subsequently being freed by N CPUs
degenerates to contending on a single lock, which is no worse than before. When
more than one CPU are allocating files, even if they are always freed by
different CPUs, there will be more parallelism than the single-lock case.
Testing results:
On a 2 socket, 8 core opteron, I measure the number of times the lock is taken
to remove the file, the number of times it is removed by the same CPU that
added it, and the number of times it is removed by the same node that added it.
Booting: locks= 25049 cpu-hits= 23174 (92.5%) node-hits= 23945 (95.6%)
kbuild -j16 locks=2281913 cpu-hits=2208126 (96.8%) node-hits=2252674 (98.7%)
dbench 64 locks=4306582 cpu-hits=4287247 (99.6%) node-hits=4299527 (99.8%)
So a file is removed from the same CPU it was added by over 90% of the time.
It remains within the same node 95% of the time.
Tim Chen ran some numbers for a 64 thread Nehalem system performing a compile.
throughput
2.6.34-rc2 24.5
+patch 24.9
us sys idle IO wait (in %)
2.6.34-rc2 51.25 28.25 17.25 3.25
+patch 53.75 18.5 19 8.75
So significantly less CPU time spent in kernel code, higher idle time and
slightly higher throughput.
Single threaded performance difference was within the noise of microbenchmarks.
That is not to say penalty does not exist, the code is larger and more memory
accesses required so it will be slightly slower.
Cc: linux-kernel@vger.kernel.org
Cc: Tim Chen <tim.c.chen@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Nick Piggin <npiggin@kernel.dk>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2010-08-17 12:37:38 -06:00
|
|
|
lg_local_lock_cpu(files_lglock, file_list_cpu(file));
|
2005-10-30 16:02:16 -07:00
|
|
|
list_del_init(&file->f_u.fu_list);
|
fs: scale files_lock
fs: scale files_lock
Improve scalability of files_lock by adding per-cpu, per-sb files lists,
protected with an lglock. The lglock provides fast access to the per-cpu lists
to add and remove files. It also provides a snapshot of all the per-cpu lists
(although this is very slow).
One difficulty with this approach is that a file can be removed from the list
by another CPU. We must track which per-cpu list the file is on with a new
variale in the file struct (packed into a hole on 64-bit archs). Scalability
could suffer if files are frequently removed from different cpu's list.
However loads with frequent removal of files imply short interval between
adding and removing the files, and the scheduler attempts to avoid moving
processes too far away. Also, even in the case of cross-CPU removal, the
hardware has much more opportunity to parallelise cacheline transfers with N
cachelines than with 1.
A worst-case test of 1 CPU allocating files subsequently being freed by N CPUs
degenerates to contending on a single lock, which is no worse than before. When
more than one CPU are allocating files, even if they are always freed by
different CPUs, there will be more parallelism than the single-lock case.
Testing results:
On a 2 socket, 8 core opteron, I measure the number of times the lock is taken
to remove the file, the number of times it is removed by the same CPU that
added it, and the number of times it is removed by the same node that added it.
Booting: locks= 25049 cpu-hits= 23174 (92.5%) node-hits= 23945 (95.6%)
kbuild -j16 locks=2281913 cpu-hits=2208126 (96.8%) node-hits=2252674 (98.7%)
dbench 64 locks=4306582 cpu-hits=4287247 (99.6%) node-hits=4299527 (99.8%)
So a file is removed from the same CPU it was added by over 90% of the time.
It remains within the same node 95% of the time.
Tim Chen ran some numbers for a 64 thread Nehalem system performing a compile.
throughput
2.6.34-rc2 24.5
+patch 24.9
us sys idle IO wait (in %)
2.6.34-rc2 51.25 28.25 17.25 3.25
+patch 53.75 18.5 19 8.75
So significantly less CPU time spent in kernel code, higher idle time and
slightly higher throughput.
Single threaded performance difference was within the noise of microbenchmarks.
That is not to say penalty does not exist, the code is larger and more memory
accesses required so it will be slightly slower.
Cc: linux-kernel@vger.kernel.org
Cc: Tim Chen <tim.c.chen@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Nick Piggin <npiggin@kernel.dk>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2010-08-17 12:37:38 -06:00
|
|
|
lg_local_unlock_cpu(files_lglock, file_list_cpu(file));
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
fs: scale files_lock
fs: scale files_lock
Improve scalability of files_lock by adding per-cpu, per-sb files lists,
protected with an lglock. The lglock provides fast access to the per-cpu lists
to add and remove files. It also provides a snapshot of all the per-cpu lists
(although this is very slow).
One difficulty with this approach is that a file can be removed from the list
by another CPU. We must track which per-cpu list the file is on with a new
variale in the file struct (packed into a hole on 64-bit archs). Scalability
could suffer if files are frequently removed from different cpu's list.
However loads with frequent removal of files imply short interval between
adding and removing the files, and the scheduler attempts to avoid moving
processes too far away. Also, even in the case of cross-CPU removal, the
hardware has much more opportunity to parallelise cacheline transfers with N
cachelines than with 1.
A worst-case test of 1 CPU allocating files subsequently being freed by N CPUs
degenerates to contending on a single lock, which is no worse than before. When
more than one CPU are allocating files, even if they are always freed by
different CPUs, there will be more parallelism than the single-lock case.
Testing results:
On a 2 socket, 8 core opteron, I measure the number of times the lock is taken
to remove the file, the number of times it is removed by the same CPU that
added it, and the number of times it is removed by the same node that added it.
Booting: locks= 25049 cpu-hits= 23174 (92.5%) node-hits= 23945 (95.6%)
kbuild -j16 locks=2281913 cpu-hits=2208126 (96.8%) node-hits=2252674 (98.7%)
dbench 64 locks=4306582 cpu-hits=4287247 (99.6%) node-hits=4299527 (99.8%)
So a file is removed from the same CPU it was added by over 90% of the time.
It remains within the same node 95% of the time.
Tim Chen ran some numbers for a 64 thread Nehalem system performing a compile.
throughput
2.6.34-rc2 24.5
+patch 24.9
us sys idle IO wait (in %)
2.6.34-rc2 51.25 28.25 17.25 3.25
+patch 53.75 18.5 19 8.75
So significantly less CPU time spent in kernel code, higher idle time and
slightly higher throughput.
Single threaded performance difference was within the noise of microbenchmarks.
That is not to say penalty does not exist, the code is larger and more memory
accesses required so it will be slightly slower.
Cc: linux-kernel@vger.kernel.org
Cc: Tim Chen <tim.c.chen@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Nick Piggin <npiggin@kernel.dk>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2010-08-17 12:37:38 -06:00
|
|
|
#ifdef CONFIG_SMP
|
|
|
|
|
|
|
|
/*
|
|
|
|
* These macros iterate all files on all CPUs for a given superblock.
|
|
|
|
* files_lglock must be held globally.
|
|
|
|
*/
|
|
|
|
#define do_file_list_for_each_entry(__sb, __file) \
|
|
|
|
{ \
|
|
|
|
int i; \
|
|
|
|
for_each_possible_cpu(i) { \
|
|
|
|
struct list_head *list; \
|
|
|
|
list = per_cpu_ptr((__sb)->s_files, i); \
|
|
|
|
list_for_each_entry((__file), list, f_u.fu_list)
|
|
|
|
|
|
|
|
#define while_file_list_for_each_entry \
|
|
|
|
} \
|
|
|
|
}
|
|
|
|
|
|
|
|
#else
|
|
|
|
|
|
|
|
#define do_file_list_for_each_entry(__sb, __file) \
|
|
|
|
{ \
|
|
|
|
struct list_head *list; \
|
|
|
|
list = &(sb)->s_files; \
|
|
|
|
list_for_each_entry((__file), list, f_u.fu_list)
|
|
|
|
|
|
|
|
#define while_file_list_for_each_entry \
|
|
|
|
}
|
|
|
|
|
|
|
|
#endif
|
|
|
|
|
2005-04-16 16:20:36 -06:00
|
|
|
int fs_may_remount_ro(struct super_block *sb)
|
|
|
|
{
|
2007-10-19 00:39:56 -06:00
|
|
|
struct file *file;
|
2005-04-16 16:20:36 -06:00
|
|
|
/* Check that no files are currently opened for writing. */
|
fs: scale files_lock
fs: scale files_lock
Improve scalability of files_lock by adding per-cpu, per-sb files lists,
protected with an lglock. The lglock provides fast access to the per-cpu lists
to add and remove files. It also provides a snapshot of all the per-cpu lists
(although this is very slow).
One difficulty with this approach is that a file can be removed from the list
by another CPU. We must track which per-cpu list the file is on with a new
variale in the file struct (packed into a hole on 64-bit archs). Scalability
could suffer if files are frequently removed from different cpu's list.
However loads with frequent removal of files imply short interval between
adding and removing the files, and the scheduler attempts to avoid moving
processes too far away. Also, even in the case of cross-CPU removal, the
hardware has much more opportunity to parallelise cacheline transfers with N
cachelines than with 1.
A worst-case test of 1 CPU allocating files subsequently being freed by N CPUs
degenerates to contending on a single lock, which is no worse than before. When
more than one CPU are allocating files, even if they are always freed by
different CPUs, there will be more parallelism than the single-lock case.
Testing results:
On a 2 socket, 8 core opteron, I measure the number of times the lock is taken
to remove the file, the number of times it is removed by the same CPU that
added it, and the number of times it is removed by the same node that added it.
Booting: locks= 25049 cpu-hits= 23174 (92.5%) node-hits= 23945 (95.6%)
kbuild -j16 locks=2281913 cpu-hits=2208126 (96.8%) node-hits=2252674 (98.7%)
dbench 64 locks=4306582 cpu-hits=4287247 (99.6%) node-hits=4299527 (99.8%)
So a file is removed from the same CPU it was added by over 90% of the time.
It remains within the same node 95% of the time.
Tim Chen ran some numbers for a 64 thread Nehalem system performing a compile.
throughput
2.6.34-rc2 24.5
+patch 24.9
us sys idle IO wait (in %)
2.6.34-rc2 51.25 28.25 17.25 3.25
+patch 53.75 18.5 19 8.75
So significantly less CPU time spent in kernel code, higher idle time and
slightly higher throughput.
Single threaded performance difference was within the noise of microbenchmarks.
That is not to say penalty does not exist, the code is larger and more memory
accesses required so it will be slightly slower.
Cc: linux-kernel@vger.kernel.org
Cc: Tim Chen <tim.c.chen@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Nick Piggin <npiggin@kernel.dk>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2010-08-17 12:37:38 -06:00
|
|
|
lg_global_lock(files_lglock);
|
|
|
|
do_file_list_for_each_entry(sb, file) {
|
2006-12-08 03:36:35 -07:00
|
|
|
struct inode *inode = file->f_path.dentry->d_inode;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
|
|
|
/* File with pending delete? */
|
|
|
|
if (inode->i_nlink == 0)
|
|
|
|
goto too_bad;
|
|
|
|
|
|
|
|
/* Writeable file? */
|
|
|
|
if (S_ISREG(inode->i_mode) && (file->f_mode & FMODE_WRITE))
|
|
|
|
goto too_bad;
|
fs: scale files_lock
fs: scale files_lock
Improve scalability of files_lock by adding per-cpu, per-sb files lists,
protected with an lglock. The lglock provides fast access to the per-cpu lists
to add and remove files. It also provides a snapshot of all the per-cpu lists
(although this is very slow).
One difficulty with this approach is that a file can be removed from the list
by another CPU. We must track which per-cpu list the file is on with a new
variale in the file struct (packed into a hole on 64-bit archs). Scalability
could suffer if files are frequently removed from different cpu's list.
However loads with frequent removal of files imply short interval between
adding and removing the files, and the scheduler attempts to avoid moving
processes too far away. Also, even in the case of cross-CPU removal, the
hardware has much more opportunity to parallelise cacheline transfers with N
cachelines than with 1.
A worst-case test of 1 CPU allocating files subsequently being freed by N CPUs
degenerates to contending on a single lock, which is no worse than before. When
more than one CPU are allocating files, even if they are always freed by
different CPUs, there will be more parallelism than the single-lock case.
Testing results:
On a 2 socket, 8 core opteron, I measure the number of times the lock is taken
to remove the file, the number of times it is removed by the same CPU that
added it, and the number of times it is removed by the same node that added it.
Booting: locks= 25049 cpu-hits= 23174 (92.5%) node-hits= 23945 (95.6%)
kbuild -j16 locks=2281913 cpu-hits=2208126 (96.8%) node-hits=2252674 (98.7%)
dbench 64 locks=4306582 cpu-hits=4287247 (99.6%) node-hits=4299527 (99.8%)
So a file is removed from the same CPU it was added by over 90% of the time.
It remains within the same node 95% of the time.
Tim Chen ran some numbers for a 64 thread Nehalem system performing a compile.
throughput
2.6.34-rc2 24.5
+patch 24.9
us sys idle IO wait (in %)
2.6.34-rc2 51.25 28.25 17.25 3.25
+patch 53.75 18.5 19 8.75
So significantly less CPU time spent in kernel code, higher idle time and
slightly higher throughput.
Single threaded performance difference was within the noise of microbenchmarks.
That is not to say penalty does not exist, the code is larger and more memory
accesses required so it will be slightly slower.
Cc: linux-kernel@vger.kernel.org
Cc: Tim Chen <tim.c.chen@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Nick Piggin <npiggin@kernel.dk>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2010-08-17 12:37:38 -06:00
|
|
|
} while_file_list_for_each_entry;
|
|
|
|
lg_global_unlock(files_lglock);
|
2005-04-16 16:20:36 -06:00
|
|
|
return 1; /* Tis' cool bro. */
|
|
|
|
too_bad:
|
fs: scale files_lock
fs: scale files_lock
Improve scalability of files_lock by adding per-cpu, per-sb files lists,
protected with an lglock. The lglock provides fast access to the per-cpu lists
to add and remove files. It also provides a snapshot of all the per-cpu lists
(although this is very slow).
One difficulty with this approach is that a file can be removed from the list
by another CPU. We must track which per-cpu list the file is on with a new
variale in the file struct (packed into a hole on 64-bit archs). Scalability
could suffer if files are frequently removed from different cpu's list.
However loads with frequent removal of files imply short interval between
adding and removing the files, and the scheduler attempts to avoid moving
processes too far away. Also, even in the case of cross-CPU removal, the
hardware has much more opportunity to parallelise cacheline transfers with N
cachelines than with 1.
A worst-case test of 1 CPU allocating files subsequently being freed by N CPUs
degenerates to contending on a single lock, which is no worse than before. When
more than one CPU are allocating files, even if they are always freed by
different CPUs, there will be more parallelism than the single-lock case.
Testing results:
On a 2 socket, 8 core opteron, I measure the number of times the lock is taken
to remove the file, the number of times it is removed by the same CPU that
added it, and the number of times it is removed by the same node that added it.
Booting: locks= 25049 cpu-hits= 23174 (92.5%) node-hits= 23945 (95.6%)
kbuild -j16 locks=2281913 cpu-hits=2208126 (96.8%) node-hits=2252674 (98.7%)
dbench 64 locks=4306582 cpu-hits=4287247 (99.6%) node-hits=4299527 (99.8%)
So a file is removed from the same CPU it was added by over 90% of the time.
It remains within the same node 95% of the time.
Tim Chen ran some numbers for a 64 thread Nehalem system performing a compile.
throughput
2.6.34-rc2 24.5
+patch 24.9
us sys idle IO wait (in %)
2.6.34-rc2 51.25 28.25 17.25 3.25
+patch 53.75 18.5 19 8.75
So significantly less CPU time spent in kernel code, higher idle time and
slightly higher throughput.
Single threaded performance difference was within the noise of microbenchmarks.
That is not to say penalty does not exist, the code is larger and more memory
accesses required so it will be slightly slower.
Cc: linux-kernel@vger.kernel.org
Cc: Tim Chen <tim.c.chen@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Nick Piggin <npiggin@kernel.dk>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2010-08-17 12:37:38 -06:00
|
|
|
lg_global_unlock(files_lglock);
|
2005-04-16 16:20:36 -06:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-04-26 04:25:56 -06:00
|
|
|
/**
|
|
|
|
* mark_files_ro - mark all files read-only
|
|
|
|
* @sb: superblock in question
|
|
|
|
*
|
|
|
|
* All files are marked read-only. We don't care about pending
|
|
|
|
* delete files so this should be used in 'force' mode only.
|
|
|
|
*/
|
|
|
|
void mark_files_ro(struct super_block *sb)
|
|
|
|
{
|
|
|
|
struct file *f;
|
|
|
|
|
|
|
|
retry:
|
fs: scale files_lock
fs: scale files_lock
Improve scalability of files_lock by adding per-cpu, per-sb files lists,
protected with an lglock. The lglock provides fast access to the per-cpu lists
to add and remove files. It also provides a snapshot of all the per-cpu lists
(although this is very slow).
One difficulty with this approach is that a file can be removed from the list
by another CPU. We must track which per-cpu list the file is on with a new
variale in the file struct (packed into a hole on 64-bit archs). Scalability
could suffer if files are frequently removed from different cpu's list.
However loads with frequent removal of files imply short interval between
adding and removing the files, and the scheduler attempts to avoid moving
processes too far away. Also, even in the case of cross-CPU removal, the
hardware has much more opportunity to parallelise cacheline transfers with N
cachelines than with 1.
A worst-case test of 1 CPU allocating files subsequently being freed by N CPUs
degenerates to contending on a single lock, which is no worse than before. When
more than one CPU are allocating files, even if they are always freed by
different CPUs, there will be more parallelism than the single-lock case.
Testing results:
On a 2 socket, 8 core opteron, I measure the number of times the lock is taken
to remove the file, the number of times it is removed by the same CPU that
added it, and the number of times it is removed by the same node that added it.
Booting: locks= 25049 cpu-hits= 23174 (92.5%) node-hits= 23945 (95.6%)
kbuild -j16 locks=2281913 cpu-hits=2208126 (96.8%) node-hits=2252674 (98.7%)
dbench 64 locks=4306582 cpu-hits=4287247 (99.6%) node-hits=4299527 (99.8%)
So a file is removed from the same CPU it was added by over 90% of the time.
It remains within the same node 95% of the time.
Tim Chen ran some numbers for a 64 thread Nehalem system performing a compile.
throughput
2.6.34-rc2 24.5
+patch 24.9
us sys idle IO wait (in %)
2.6.34-rc2 51.25 28.25 17.25 3.25
+patch 53.75 18.5 19 8.75
So significantly less CPU time spent in kernel code, higher idle time and
slightly higher throughput.
Single threaded performance difference was within the noise of microbenchmarks.
That is not to say penalty does not exist, the code is larger and more memory
accesses required so it will be slightly slower.
Cc: linux-kernel@vger.kernel.org
Cc: Tim Chen <tim.c.chen@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Nick Piggin <npiggin@kernel.dk>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2010-08-17 12:37:38 -06:00
|
|
|
lg_global_lock(files_lglock);
|
|
|
|
do_file_list_for_each_entry(sb, f) {
|
2009-04-26 04:25:56 -06:00
|
|
|
struct vfsmount *mnt;
|
|
|
|
if (!S_ISREG(f->f_path.dentry->d_inode->i_mode))
|
|
|
|
continue;
|
|
|
|
if (!file_count(f))
|
|
|
|
continue;
|
|
|
|
if (!(f->f_mode & FMODE_WRITE))
|
|
|
|
continue;
|
2010-03-05 14:42:01 -07:00
|
|
|
spin_lock(&f->f_lock);
|
2009-04-26 04:25:56 -06:00
|
|
|
f->f_mode &= ~FMODE_WRITE;
|
2010-03-05 14:42:01 -07:00
|
|
|
spin_unlock(&f->f_lock);
|
2009-04-26 04:25:56 -06:00
|
|
|
if (file_check_writeable(f) != 0)
|
|
|
|
continue;
|
|
|
|
file_release_write(f);
|
|
|
|
mnt = mntget(f->f_path.mnt);
|
2010-08-17 12:37:35 -06:00
|
|
|
/* This can sleep, so we can't hold the spinlock. */
|
fs: scale files_lock
fs: scale files_lock
Improve scalability of files_lock by adding per-cpu, per-sb files lists,
protected with an lglock. The lglock provides fast access to the per-cpu lists
to add and remove files. It also provides a snapshot of all the per-cpu lists
(although this is very slow).
One difficulty with this approach is that a file can be removed from the list
by another CPU. We must track which per-cpu list the file is on with a new
variale in the file struct (packed into a hole on 64-bit archs). Scalability
could suffer if files are frequently removed from different cpu's list.
However loads with frequent removal of files imply short interval between
adding and removing the files, and the scheduler attempts to avoid moving
processes too far away. Also, even in the case of cross-CPU removal, the
hardware has much more opportunity to parallelise cacheline transfers with N
cachelines than with 1.
A worst-case test of 1 CPU allocating files subsequently being freed by N CPUs
degenerates to contending on a single lock, which is no worse than before. When
more than one CPU are allocating files, even if they are always freed by
different CPUs, there will be more parallelism than the single-lock case.
Testing results:
On a 2 socket, 8 core opteron, I measure the number of times the lock is taken
to remove the file, the number of times it is removed by the same CPU that
added it, and the number of times it is removed by the same node that added it.
Booting: locks= 25049 cpu-hits= 23174 (92.5%) node-hits= 23945 (95.6%)
kbuild -j16 locks=2281913 cpu-hits=2208126 (96.8%) node-hits=2252674 (98.7%)
dbench 64 locks=4306582 cpu-hits=4287247 (99.6%) node-hits=4299527 (99.8%)
So a file is removed from the same CPU it was added by over 90% of the time.
It remains within the same node 95% of the time.
Tim Chen ran some numbers for a 64 thread Nehalem system performing a compile.
throughput
2.6.34-rc2 24.5
+patch 24.9
us sys idle IO wait (in %)
2.6.34-rc2 51.25 28.25 17.25 3.25
+patch 53.75 18.5 19 8.75
So significantly less CPU time spent in kernel code, higher idle time and
slightly higher throughput.
Single threaded performance difference was within the noise of microbenchmarks.
That is not to say penalty does not exist, the code is larger and more memory
accesses required so it will be slightly slower.
Cc: linux-kernel@vger.kernel.org
Cc: Tim Chen <tim.c.chen@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Nick Piggin <npiggin@kernel.dk>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2010-08-17 12:37:38 -06:00
|
|
|
lg_global_unlock(files_lglock);
|
2009-04-26 04:25:56 -06:00
|
|
|
mnt_drop_write(mnt);
|
|
|
|
mntput(mnt);
|
|
|
|
goto retry;
|
fs: scale files_lock
fs: scale files_lock
Improve scalability of files_lock by adding per-cpu, per-sb files lists,
protected with an lglock. The lglock provides fast access to the per-cpu lists
to add and remove files. It also provides a snapshot of all the per-cpu lists
(although this is very slow).
One difficulty with this approach is that a file can be removed from the list
by another CPU. We must track which per-cpu list the file is on with a new
variale in the file struct (packed into a hole on 64-bit archs). Scalability
could suffer if files are frequently removed from different cpu's list.
However loads with frequent removal of files imply short interval between
adding and removing the files, and the scheduler attempts to avoid moving
processes too far away. Also, even in the case of cross-CPU removal, the
hardware has much more opportunity to parallelise cacheline transfers with N
cachelines than with 1.
A worst-case test of 1 CPU allocating files subsequently being freed by N CPUs
degenerates to contending on a single lock, which is no worse than before. When
more than one CPU are allocating files, even if they are always freed by
different CPUs, there will be more parallelism than the single-lock case.
Testing results:
On a 2 socket, 8 core opteron, I measure the number of times the lock is taken
to remove the file, the number of times it is removed by the same CPU that
added it, and the number of times it is removed by the same node that added it.
Booting: locks= 25049 cpu-hits= 23174 (92.5%) node-hits= 23945 (95.6%)
kbuild -j16 locks=2281913 cpu-hits=2208126 (96.8%) node-hits=2252674 (98.7%)
dbench 64 locks=4306582 cpu-hits=4287247 (99.6%) node-hits=4299527 (99.8%)
So a file is removed from the same CPU it was added by over 90% of the time.
It remains within the same node 95% of the time.
Tim Chen ran some numbers for a 64 thread Nehalem system performing a compile.
throughput
2.6.34-rc2 24.5
+patch 24.9
us sys idle IO wait (in %)
2.6.34-rc2 51.25 28.25 17.25 3.25
+patch 53.75 18.5 19 8.75
So significantly less CPU time spent in kernel code, higher idle time and
slightly higher throughput.
Single threaded performance difference was within the noise of microbenchmarks.
That is not to say penalty does not exist, the code is larger and more memory
accesses required so it will be slightly slower.
Cc: linux-kernel@vger.kernel.org
Cc: Tim Chen <tim.c.chen@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Nick Piggin <npiggin@kernel.dk>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2010-08-17 12:37:38 -06:00
|
|
|
} while_file_list_for_each_entry;
|
|
|
|
lg_global_unlock(files_lglock);
|
2009-04-26 04:25:56 -06:00
|
|
|
}
|
|
|
|
|
2005-04-16 16:20:36 -06:00
|
|
|
void __init files_init(unsigned long mempages)
|
|
|
|
{
|
2010-10-26 15:22:44 -06:00
|
|
|
unsigned long n;
|
2008-12-10 10:35:45 -07:00
|
|
|
|
|
|
|
filp_cachep = kmem_cache_create("filp", sizeof(struct file), 0,
|
|
|
|
SLAB_HWCACHE_ALIGN | SLAB_PANIC, NULL);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* One file with associated inode and dcache is very roughly 1K.
|
2005-04-16 16:20:36 -06:00
|
|
|
* Per default don't use more than 10% of our memory for files.
|
|
|
|
*/
|
|
|
|
|
|
|
|
n = (mempages * (PAGE_SIZE / 1024)) / 10;
|
2010-10-26 15:22:44 -06:00
|
|
|
files_stat.max_files = max_t(unsigned long, n, NR_FILE);
|
2005-09-09 14:04:13 -06:00
|
|
|
files_defer_init();
|
fs: scale files_lock
fs: scale files_lock
Improve scalability of files_lock by adding per-cpu, per-sb files lists,
protected with an lglock. The lglock provides fast access to the per-cpu lists
to add and remove files. It also provides a snapshot of all the per-cpu lists
(although this is very slow).
One difficulty with this approach is that a file can be removed from the list
by another CPU. We must track which per-cpu list the file is on with a new
variale in the file struct (packed into a hole on 64-bit archs). Scalability
could suffer if files are frequently removed from different cpu's list.
However loads with frequent removal of files imply short interval between
adding and removing the files, and the scheduler attempts to avoid moving
processes too far away. Also, even in the case of cross-CPU removal, the
hardware has much more opportunity to parallelise cacheline transfers with N
cachelines than with 1.
A worst-case test of 1 CPU allocating files subsequently being freed by N CPUs
degenerates to contending on a single lock, which is no worse than before. When
more than one CPU are allocating files, even if they are always freed by
different CPUs, there will be more parallelism than the single-lock case.
Testing results:
On a 2 socket, 8 core opteron, I measure the number of times the lock is taken
to remove the file, the number of times it is removed by the same CPU that
added it, and the number of times it is removed by the same node that added it.
Booting: locks= 25049 cpu-hits= 23174 (92.5%) node-hits= 23945 (95.6%)
kbuild -j16 locks=2281913 cpu-hits=2208126 (96.8%) node-hits=2252674 (98.7%)
dbench 64 locks=4306582 cpu-hits=4287247 (99.6%) node-hits=4299527 (99.8%)
So a file is removed from the same CPU it was added by over 90% of the time.
It remains within the same node 95% of the time.
Tim Chen ran some numbers for a 64 thread Nehalem system performing a compile.
throughput
2.6.34-rc2 24.5
+patch 24.9
us sys idle IO wait (in %)
2.6.34-rc2 51.25 28.25 17.25 3.25
+patch 53.75 18.5 19 8.75
So significantly less CPU time spent in kernel code, higher idle time and
slightly higher throughput.
Single threaded performance difference was within the noise of microbenchmarks.
That is not to say penalty does not exist, the code is larger and more memory
accesses required so it will be slightly slower.
Cc: linux-kernel@vger.kernel.org
Cc: Tim Chen <tim.c.chen@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Nick Piggin <npiggin@kernel.dk>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2010-08-17 12:37:38 -06:00
|
|
|
lg_lock_init(files_lglock);
|
2006-06-23 03:05:41 -06:00
|
|
|
percpu_counter_init(&nr_files, 0);
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|