lkml.org 
[lkml]   [1997]   [Mar]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: fs/inode.c reimplementation

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


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