From owner-freebsd-hackers  Wed Jul  7 16:23:38 1999
Delivered-To: freebsd-hackers@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2])
	by hub.freebsd.org (Postfix) with ESMTP
	id 8A3DD14D34; Wed,  7 Jul 1999 16:23:33 -0700 (PDT)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id QAA94794;
	Wed, 7 Jul 1999 16:23:29 -0700 (PDT)
	(envelope-from dillon)
Date: Wed, 7 Jul 1999 16:23:29 -0700 (PDT)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <199907072323.QAA94794@apollo.backplane.com>
To: David Greenman <dg@root.com>
Cc: freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG
Subject: Re: Heh heh, humorous lockup 
References:  <199907072309.QAA23725@implode.root.com>
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

:>    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.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>



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