From owner-freebsd-fs Wed Apr 23 08:57:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA06489 for fs-outgoing; Wed, 23 Apr 1997 08:57:07 -0700 (PDT) Received: from critter.dk.tfs.com ([140.145.230.252]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA06483 for ; Wed, 23 Apr 1997 08:57:05 -0700 (PDT) Received: from critter (localhost [127.0.0.1]) by critter.dk.tfs.com (8.8.5/8.8.5) with ESMTP id RAA01286 for ; Wed, 23 Apr 1997 17:55:34 +0200 (CEST) To: fs@freebsd.org Subject: the namei cache... From: Poul-Henning Kamp Date: Wed, 23 Apr 1997 17:55:34 +0200 Message-ID: <1284.861810934@critter> Sender: owner-fs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I've been sticking my nose in the namei cache again, and that got me wondering. Consider this: We add a linked list to vnodes that represent directories and hook all the cache entires that are relative to that directory onto that list (sorted by name, or maybe LRU ?), rather than finding them through the hash list. Benefit: We can release the cache entries at the time we recycle the vnode, instead of the lazy release when we stumble across an invalid cache entry, resulting in a better cache utilization. Benefit: We can do away with the v_id field, unless other parts of the kernel need it. Benefit: We don't rely on the hash to level things out for us. Benefit: We can lock with finer and more logical granularity (ie. per vnode) in the cache than we could otherwise do. Neutral: We still keep the LRU list around to reclain little used cache entries. Almost neutral: We save the storage for the hash-table but the vnode becomes 4 bytes bigger. This is close to a break even, since the size of the hash table is found from desiredvnodes... Comments ? Have I overlooked something fundamental ? -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so.