Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 07 Jul 1999 16:34:59 -0700
From:      David Greenman <dg@root.com>
To:        Matthew Dillon <dillon@apollo.backplane.com>
Cc:        freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG
Subject:   Re: Heh heh, humorous lockup 
Message-ID:  <199907072334.QAA23809@implode.root.com>
In-Reply-To: Your message of "Wed, 07 Jul 1999 16:23:29 PDT." <199907072323.QAA94794@apollo.backplane.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
>:>    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.
>
>    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.

   We've been here before, a couple of times. This started to become an issue
when the limits were removed and has gotten worse as the vnode and fsnode
structs have grown over time. We're running into some limits on how much
space we can give to the kernel since there are a number of folks which
think that 3GB of process VA space is a minimum. I tend to think that the
2GB/2GB split that I use on wcarchive is probably more appropriate as a
default, but like I say, others disagree.

-DG

David Greenman
Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org
Creator of high-performance Internet servers - http://www.terasolutions.com


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?199907072334.QAA23809>