diff options
author | Eric Dumazet <dada1@cosmosbay.com> | 2007-05-08 03:26:18 -0400 |
---|---|---|
committer | Linus Torvalds <torvalds@woody.linux-foundation.org> | 2007-05-08 14:15:03 -0400 |
commit | c23fbb6bcb3eb9cdf39a103edadf57bde8ce309c (patch) | |
tree | d79ab2278774de2c1a8061aa948ed068902e87b4 /Documentation/filesystems | |
parent | 2793274298c4423d79701e9a8190f2940bf3c785 (diff) |
VFS: delay the dentry name generation on sockets and pipes
1) Introduces a new method in 'struct dentry_operations'. This method
called d_dname() might be called from d_path() to build a pathname for
special filesystems. It is called without locks.
Future patches (if we succeed in having one common dentry for all
pipes/sockets) may need to change prototype of this method, but we now
use : char *d_dname(struct dentry *dentry, char *buffer, int buflen);
2) Adds a dynamic_dname() helper function that eases d_dname() implementations
3) Defines d_dname method for sockets : No more sprintf() at socket
creation. This is delayed up to the moment someone does an access to
/proc/pid/fd/...
4) Defines d_dname method for pipes : No more sprintf() at pipe
creation. This is delayed up to the moment someone does an access to
/proc/pid/fd/...
A benchmark consisting of 1.000.000 calls to pipe()/close()/close() gives a
*nice* speedup on my Pentium(M) 1.6 Ghz :
3.090 s instead of 3.450 s
Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
Acked-by: Christoph Hellwig <hch@infradead.org>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'Documentation/filesystems')
-rw-r--r-- | Documentation/filesystems/Locking | 2 | ||||
-rw-r--r-- | Documentation/filesystems/vfs.txt | 23 |
2 files changed, 24 insertions, 1 deletions
diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking index 28bfea75bcf2..59c14159cc47 100644 --- a/Documentation/filesystems/Locking +++ b/Documentation/filesystems/Locking | |||
@@ -15,6 +15,7 @@ prototypes: | |||
15 | int (*d_delete)(struct dentry *); | 15 | int (*d_delete)(struct dentry *); |
16 | void (*d_release)(struct dentry *); | 16 | void (*d_release)(struct dentry *); |
17 | void (*d_iput)(struct dentry *, struct inode *); | 17 | void (*d_iput)(struct dentry *, struct inode *); |
18 | char *(*d_dname)((struct dentry *dentry, char *buffer, int buflen); | ||
18 | 19 | ||
19 | locking rules: | 20 | locking rules: |
20 | none have BKL | 21 | none have BKL |
@@ -25,6 +26,7 @@ d_compare: no yes no no | |||
25 | d_delete: yes no yes no | 26 | d_delete: yes no yes no |
26 | d_release: no no no yes | 27 | d_release: no no no yes |
27 | d_iput: no no no yes | 28 | d_iput: no no no yes |
29 | d_dname: no no no no | ||
28 | 30 | ||
29 | --------------------------- inode_operations --------------------------- | 31 | --------------------------- inode_operations --------------------------- |
30 | prototypes: | 32 | prototypes: |
diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt index ea271f2d3954..a47cc819f37b 100644 --- a/Documentation/filesystems/vfs.txt +++ b/Documentation/filesystems/vfs.txt | |||
@@ -827,7 +827,7 @@ This describes how a filesystem can overload the standard dentry | |||
827 | operations. Dentries and the dcache are the domain of the VFS and the | 827 | operations. Dentries and the dcache are the domain of the VFS and the |
828 | individual filesystem implementations. Device drivers have no business | 828 | individual filesystem implementations. Device drivers have no business |
829 | here. These methods may be set to NULL, as they are either optional or | 829 | here. These methods may be set to NULL, as they are either optional or |
830 | the VFS uses a default. As of kernel 2.6.13, the following members are | 830 | the VFS uses a default. As of kernel 2.6.22, the following members are |
831 | defined: | 831 | defined: |
832 | 832 | ||
833 | struct dentry_operations { | 833 | struct dentry_operations { |
@@ -837,6 +837,7 @@ struct dentry_operations { | |||
837 | int (*d_delete)(struct dentry *); | 837 | int (*d_delete)(struct dentry *); |
838 | void (*d_release)(struct dentry *); | 838 | void (*d_release)(struct dentry *); |
839 | void (*d_iput)(struct dentry *, struct inode *); | 839 | void (*d_iput)(struct dentry *, struct inode *); |
840 | char *(*d_dname)(struct dentry *, char *, int); | ||
840 | }; | 841 | }; |
841 | 842 | ||
842 | d_revalidate: called when the VFS needs to revalidate a dentry. This | 843 | d_revalidate: called when the VFS needs to revalidate a dentry. This |
@@ -859,6 +860,26 @@ struct dentry_operations { | |||
859 | VFS calls iput(). If you define this method, you must call | 860 | VFS calls iput(). If you define this method, you must call |
860 | iput() yourself | 861 | iput() yourself |
861 | 862 | ||
863 | d_dname: called when the pathname of a dentry should be generated. | ||
864 | Usefull for some pseudo filesystems (sockfs, pipefs, ...) to delay | ||
865 | pathname generation. (Instead of doing it when dentry is created, | ||
866 | its done only when the path is needed.). Real filesystems probably | ||
867 | dont want to use it, because their dentries are present in global | ||
868 | dcache hash, so their hash should be an invariant. As no lock is | ||
869 | held, d_dname() should not try to modify the dentry itself, unless | ||
870 | appropriate SMP safety is used. CAUTION : d_path() logic is quite | ||
871 | tricky. The correct way to return for example "Hello" is to put it | ||
872 | at the end of the buffer, and returns a pointer to the first char. | ||
873 | dynamic_dname() helper function is provided to take care of this. | ||
874 | |||
875 | Example : | ||
876 | |||
877 | static char *pipefs_dname(struct dentry *dent, char *buffer, int buflen) | ||
878 | { | ||
879 | return dynamic_dname(dentry, buffer, buflen, "pipe:[%lu]", | ||
880 | dentry->d_inode->i_ino); | ||
881 | } | ||
882 | |||
862 | Each dentry has a pointer to its parent dentry, as well as a hash list | 883 | Each dentry has a pointer to its parent dentry, as well as a hash list |
863 | of child dentries. Child dentries are basically like files in a | 884 | of child dentries. Child dentries are basically like files in a |
864 | directory. | 885 | directory. |