On Wed, 7 Jul 1999, Matthew Dillon wrote:

> :>    limit ought to work for a 4G machine
> :>
> :>    Since most of those news files were small, I think Kirk's news test code
> :>    is pretty much the worse case scenario as far as vnode allocation goes.
> :
> :   Well, I could possibly live with 256MB, but the vnode/fsnode consumption
> :seems to be getting a bit silly in the memory overhead department, even for
> :machines with 4GB of RAM. It seems like there needs to be fewer of them
> :and/or they need to go on a diet.
> :
> :-DG
> :
> :David Greenman
> 
>     Well, the problem occurs because the system has sufficient memory to keep
>     the underlying VM object around.  The current vnode code will not place
>     a vnode on the free list until the underlying VM object goes away.  The
>     60MB worth of KVM being used to hold vnodes is supporting 1GB worth
>     of cached VM pages ( associated with small files, that is ).  So even
>     though the numbers look strange, it does seem to scale.
> 
>     In order to turn the maxvnodes sysctl into a harder limit, the vnode 
>     allocation & freeing code would have to be reworked some.  Right now
>     vnodes are not placed back onto the free list until their underlying
>     VM objects go away.  We would need to make the vnode lists (which are
>     headed by mount table entries) LRU and then attempt to reuse the vnodes
>     that way, destroying the underlying VM object when necessary.
> 
>     Alternatively we can try to make the vnode structure smaller, or we
>     could try to decouple the vnode from the VM object and instead reference
>     the VM object by inode.  All I can say to that:  Yuch.  I'd rather just
>     bump up the KVM.


or do what Kirk wants to do and merge the VM and Vnode structures
I belive the UVM does a bit in this direction due to kirk's influence.

julian


> 
>                                       -Matt
>                                       Matthew Dillon 
>                                       <[EMAIL PROTECTED]>
> 
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to