Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 23 Sep 2001 15:06:36 +0200
From:      Poul-Henning Kamp <phk@critter.freebsd.dk>
To:        Matt Dillon <dillon@earth.backplane.com>
Cc:        David Greenman <dg@root.com>, Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp>, bright@wintelcom.net, hackers@FreeBSD.ORG
Subject:   Re: Conclusions on... was Re: More on the cache_purgeleafdirs() routine 
Message-ID:  <98331.1001250396@critter>
In-Reply-To: Your message of "Sun, 23 Sep 2001 03:40:33 PDT." <200109231040.f8NAeXw86352@earth.backplane.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
In message <200109231040.f8NAeXw86352@earth.backplane.com>, Matt Dillon writes:

>    Ah yes, vmiodirenable.  We should just turn it on by default now.  I've
>    been waffling too long on that.  With it off the buffer cache will 
>    remember at most vfs.maxmallocspace worth of directory data (read: not
>    very much), and without VMIO backing, which means vnodes could be
>    reclaimed immediately.  Ah!  Now I see why that clause was put
>    in... but it's obsolete now if vmiodirenable is turned on, and it
>    doesn't scale well to large-memory machines if it is left in.
>
>    If we turn vmiodirenable on then directory blocks get cached by the 
>    VM system.  There is no preferential treatment of directory blocks
>    but there doesn't need to be, the VM system does a very good job figuring
>    out which blocks to keep and which not to.

Well, benchmarks will show that.  A directory page may hold the
access to hundred files so it should not be pushed out by one file.

I think getting directory pages VM cached is The Right Way for this,
because it means that also the not-earlier used filenames become
cheaply accessible.

Things to look out for:

1. !ufs filesystems

2. inode->vnode hash/search algorithms may become much more
   important.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?98331.1001250396>