From owner-freebsd-arch Tue Mar 5 10:17:43 2002 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 6961737B426 for ; Tue, 5 Mar 2002 10:17:22 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g25IHLm71569; Tue, 5 Mar 2002 10:17:21 -0800 (PST) (envelope-from dillon) Date: Tue, 5 Mar 2002 10:17:21 -0800 (PST) From: Matthew Dillon Message-Id: <200203051817.g25IHLm71569@apollo.backplane.com> To: Seigo Tanimura , Bruce Evans , Terry Lambert , Subject: Re: reclaiming v_data of free vnodes References: <20020305214534.S4601-100000@gamplex.bde.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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 :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 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 and :. : :Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message