lkml.org 
[lkml]   [1997]   [Jul]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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


\
 
 \ /
  Last update: 2005-03-22 13:39    [W:0.078 / U:0.356 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site