Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 16 Oct 2001 20:36:26 -0700 (PDT)
From:      Matthew Dillon <dillon@apollo.backplane.com>
To:        hackers@FreeBSD.ORG
Cc:        Dag-Erling Smorgrav <des@ofug.org>, John Baldwin <jhb@FreeBSD.ORG>, Maxime Henrion <mux@qualys.com>
Subject:   First cut at kern.maxvnodes implementation
Message-ID:  <200110170336.f9H3aQI94211@apollo.backplane.com>

next in thread | raw e-mail | index | archive | help
    Here is my first cut at implementing kern.maxvnodes.  When playing with
    the sysctl()s note that kern.minvnodes also exists and may have to be
    messed around with.

	http://apollo.backplane.com/FreeBSD4/
	http://apollo.backplane.com/FreeBSD4/maxvnodes-01.diff

    These patches are for -stable only.  I'm going to get the code working
    on -stable before I try to do a cut for -current.

    There are notes up at the URL.  Note that you cannot set maxvnodes
    to an arbitrarily low number.  Well, you can, but it won't be able
    to meet the request because active vnodes (open files), buffer 
    cache references, and namei cache references (for directories containing
    children) will prevent reuse.  Thus, kern.maxvnodes is still a
    soft-maximum, but if you set it (or leave it) at a reasonable value it
    shouldn't exceed it by much.

    Another very interesting effect of this patch is that in order to
    enforce the requested kern.maxvnodes, we have to clear out vnodes that
    may still have cached pages (i.e. its the presence of cached pages
    that prevent the vnodes from being freed and cause the vnode count to
    blow out the kernel malloc area).   This means that it is actually 
    possible to stabilize physical memory use and still have a significant
    number of truely-free pages.

    The vast majority of systems never reach their programmed kern.maxvnodes,
    they run out of physical memory first and so start recycling vnodes
    that no longer have cached pages.  Those that do have large-memory 
    configurations (2G+ typically) and are typically accessing a huge
    number of small files.  For example, a cvs mirror might have this
    characteristic.

						-Matt


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?200110170336.f9H3aQI94211>