Re: fs/inode.c reimplementation

Ingo Molnar (mingo@pc5829.hil.siemens.at)
Sat, 29 Mar 1997 11:16:29 +0100 (MET)


On 28 Mar 1997, Thomas Schoebel-Theuer wrote:

> I needed to reimplement fs/inode.c due to some reasons I will explain later.

> So I need a mechanism that remembers the *real* path names at kernel
> level. To implement this, I need to reuse the inode cache for my new
> purpose. Then I noticed that dcache also remembers names, but not all
> of them. So my name remembering mechanism will also replace the current
> dcache.

very nice.

as a sidenote, here is a proof of how ineffective the current dcache
lookup mechanizm is. The following list is part of a kernel trace of a
pretty normal sys_exec(), with dcache activities cut out:

pc5829:~/trace/ktrace/samples$ cat sys_exec.out | grep dcache
Trace: c013239f <dcache_lookup+13/170> (12.71)
Trace: c013239f <dcache_lookup+13/170> (89.16)
Trace: c013250f <dcache_add+13/188> (28.65)
Trace: c013239f <dcache_lookup+13/170> (5.19)
Trace: c013239f <dcache_lookup+13/170> (84.12)
Trace: c013250f <dcache_add+13/188> (28.53)
Trace: c013239f <dcache_lookup+13/170> (78.12)
Trace: c013250f <dcache_add+13/188> (28.15)
Trace: c013239f <dcache_lookup+13/170> (7.73)
Trace: c013239f <dcache_lookup+13/170> (79.41)
Trace: c013250f <dcache_add+13/188> (29.45)

both dcache_lookup() and dcache_add() spends >tens< of microseconds on
managing a two level hash-cache ... altogether 471 microseconds ... not
ideal IMHO. [the dcache overhead is more than 10% of sys_exec() execution
time]

-- mingo