Messages in this thread | | | Date | Sat, 29 Mar 1997 11:16:29 +0100 (MET) | From | Ingo Molnar <> | Subject | Re: 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
| |