Re: namei caching of newly created files?
Bill Studenmund <[email protected]> Wed, 19 Jan 2005 17:47:31 -0800
| Newsgroups | gmane.os.netbsd.devel.performance,gmane.os.netbsd.devel.kernel |
|---|---|
| Message-ID | <[email protected]> |
On Thu, Jan 20, 2005 at 02:09:13AM +0100, Havard Eidnes wrote: > ...and here follows some revised profiling data. Unsurprisingly, > ufs_lookup still dominates completely: As it will. ufs_lookup is doing two things in the initial case. It is checking to see if the name exists, and it is looking for a slot to add the new file in if it doesn't exist. Becasue we don't build in-kernel lists of files in the directory, we have to do a full search (O(n)) of the directory to see if the name is or isn't there already. To further complicate things, we also use that initial search to look for empty entries. If we don't find the name, we will use one empty entry to store the to-be-created inode. So even if we used an in-core tree (or hash table) to tell if the file doesn't exist, we still need to know where to create it in the dir. The answer is if we do create an in-core index (via a balanced tree or a hash or whatever), we also create a linked list indicating which entries in the directory are empty. Then creating becomes O(log n) or O(c) for the lookup and O(c) for the entry-finding. The question of course is writing code to handle this and then deciding when we use it - if the directory only has a few entries or is only so big, it may be easier to just do the current linear searches. Take care, Bill
signature.asc
(application/pgp-signature, 186 B)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (NetBSD) iD8DBQFB7w2zWz+3JHUci9cRAkxwAJ0Um0kgKh95ExA9Uy1dmAHgw2MKwwCglKh6 GzhsbUecSD/oDSkC+NdITSY= =tzFo -----END PGP SIGNATURE-----