Messages in this thread | | | Date | Tue, 15 Jul 1997 21:10:58 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: dentries and a few other things. |
| |
[ Cc'd to linux-kernel, as this is a valid concern ]
On Tue, 15 Jul 1997, David Kastrup wrote: > > I'd be interested in a few details about the new dentries. I > understand that they will be used to speed up operations with SMP, and > they cannot really significantly lower the performance the way they > appear to me in the patches.
The primary reason is _not_ to improve SMP performance in particular: the primary reason for the new dentry setup is to improve performance on a more general scale.
The fact that the new code also has been written with SMP in mind makes it a lot easier to do name lookups on multiple CPU's without having to get the global kernel lock, but that's not so much because the stuff was designed for SMP as simply because I'm so much more SMP-aware these days when my main machines are multi-CPU boxes.
So in essence the basic stuff is no UP- or SMP-specific, the basic idea is just to make name lookups a lot faster.
> What I'd be interested in if there are file operations on single > processor machines for which their use might actually speed up things? > Somthing like directory searches perhaps? Don't bother digging in > details, btw.
The new dcache essentially makes inode lookup from a filename a lot faster. The way it does this is:
- keep a direct pointer to the inode in the dcache. There was a very limited form of lookup caching in 2.0.x too, but it essentially only kept the inode number in the cache, so even if you got a cache hit you still had to actually look up the inode itself. - do a better job of hashing the names, so that we get fewer hash collisions. Also, keep a 32-bit hash around to avoid doing compares on strings: we end up doing a lot fewer string compares because the new hashes are so good that we almost never get a hash collision.
The above said, being faster is only a small part of the charm of the new dcache: the much more important issue is that the way the new dcache is laid out, it allows us to do things that used to be impossible. Only one of these is the reverse mapping from inodes to names, that UNIX traditionally cannot do (getting the current working directory name is a special case of this, but the dcache is much more general than just that).
The original reason for the dcache was for Thomas Schoebel to do on-line mirroring of filesystems which required a generalized way of getting the file names from the inode. That has actually been disabled in the newer test-kernels, but that's not because it's a bad feature: I just wanted to make sure that I had the basics working really correctly before the new extra features are added back in.
Having the dcache also actually allows various low-level filesystems to do things that they couldn't do before. For example, the dcache keeps track of all parent<->child relationships, so thanks to the new dcache you can write a filesystem that has no "." or ".." entry on-disk at all, yet "." and ".." will work for the user.
(Omitting the special files "." and ".." from the on-disk filesystem can potentially make many operations much easier to do).
NOTE NOTE NOTE! For various reasons the current test-images have not generally been faster for real-world applications than previous kernels: the main reason for the slowdowns has been that the code has had various memory leaks and bad garbage collection, so physical memory was wasted that would have been better used for user processes or disk caching.
Right now it _looks_ like pre-2.1.45-7 has most of these problems fixed, but I've been wrong before..
> Am I right in guessing that the various file system drivers wil all > need to be updated for dentries?
Yes. The work isn't too onerous, but it does take some time doing. Right now only ext2/isofs/proc/NFS/autofs are supported, and both NFS and autofs have some problems because the current dcache is way too good at caching data that in some cases should be invalidated.
I don't expect this to be a major problem, most traditional filesystems are pretty trivially converted, and once I write the support routines to allow NFS to time out the dentries it wants to, the rest will also be trivial.
Linus
| |