Date: Tue, 5 Mar 2002 10:17:21 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp>, Bruce Evans <bde@zeta.org.au>, Terry Lambert <tlambert2@mindspring.com>, <arch@FreeBSD.ORG> Subject: Re: reclaiming v_data of free vnodes Message-ID: <200203051817.g25IHLm71569@apollo.backplane.com> References: <20020305214534.S4601-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
I also have some worries. The main worry is that the zone allocator
never returns memory to the system. Kernel malloc at least is able to
reuse freed memory between subsystems. This has become glaringly obvious
to me in recent weeks by virtue of the fork and process resource issues
that I've been helping Mike Silbersack out on. Anything 'large' that
commits VM to zalloc in -stable becomes a permanent fixture in the
system.
The kernel malloc subsystem is at least able to handle memory load shifts
between subsystems. It isn't great at it, but it will do it. The
zalloc subsystem cannot shift loads at all and as a consequence we
already have problems with the system running out of KVM.
I think our best bet is to either (1) adjust the existing kernel malloc
to handle odd-sized structures more efficiently. e.g. like introduce
a '192' chunk size inbetween '128' and '256'. Or, (2) just continue
patching problems with silly putty until -stable becomes obsolete. Jeff's
slab allocator work in -current promises to solve the zalloc/malloc issue
for us in -current.
Note that I am not trying to veto this work, I am just registering
my opinion that it will not help the overall situation.
-Matt
Matthew Dillon
<dillon@backplane.com>
:On Sun, 3 Mar 2002, Seigo Tanimura wrote:
:
:> Attached is the patch to use the zone allocator for in-core inodes.
:
:What are the advantages of the zone allocator here? Ordinary malloc()
:works, or should work, perfectly for ffs inodes because the size of
:an ffs inode is a power of 2 (256), and inodes are rarely allocated
:or deallocated so efficiency is unimportant. I believe the only problem
:with malloc() is that it never frees small allocations. This is not
:hard to fix. I fixed it in FreeBSD-1. This involved little more than
:fixing the "Couldfree" stuff so that it is actually useful. (Note
:that "Couldfree" column in vmstat output doesn't show the number of
:allocations that could be freed. This is usually obvious, since it
:is usually larger than the "Free" column for popular sizes after the
:system has been running for a while. IIRC, it shows the number of
:missed opportunities to free a page.)
:
:> On Tue, 26 Feb 2002 18:23:45 +0900,
:> Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp> said:
:>
:> Seigo> AFAIK, all of ffs, ifs and ext2fs utilize struct inode and
:> Seigo> dinode. They deal with the filesystem-specific data by a union. All of
:> Seigo> the filesystems should thus be able to share a single zone.
:
:The sharing is just a bug in the case of ext2fs, and other file systems
:(msdosfs, cd9660, ...) are too different to share.
:
:Your patch is very large due to namespace pollution. vm_zone_t should
:be opaque in the same way as "struct malloc_type" so that it can be
:used in headers without everything having to include <vm/vm.h> and
:<vm/vm_zone.h>.
:
:Bruce
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200203051817.g25IHLm71569>