From owner-cvs-all Wed Jun 30 11:35:24 1999 Delivered-To: cvs-all@freebsd.org Received: from shell.webmaster.com (mail.webmaster.com [209.133.28.73]) by hub.freebsd.org (Postfix) with ESMTP id 901101564D for ; Wed, 30 Jun 1999 11:35:10 -0700 (PDT) (envelope-from davids@webmaster.com) Received: from whenever ([209.133.29.2]) by shell.webmaster.com (Post.Office MTA v3.5.3 release 223 ID# 0-12345L500S10000V35) with SMTP id com; Wed, 30 Jun 1999 11:35:09 -0700 From: "David Schwartz" To: "Poul-Henning Kamp" , "Brian F. Feldman" Cc: Subject: RE: cvs commit: src/sys/kern init_main.c kern_fork.c kern_linker.c vfs_aio.c src/sys/sys proc.h Date: Wed, 30 Jun 1999 11:35:08 -0700 Message-ID: <000001bec327$47da1cd0$021d85d1@youwant.to> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-Reply-To: <43774.930765873@critter.freebsd.dk> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk You could certainly run an infrequent 'clean up' (garbage collection) where you lock down everything, free what you need to free, and then fixup everyone's pointers. So long as this is only needed in badly degenerate situations, it should theoretically be a benefit overall. You kind of have to track how many of an object you have allocated and how many you have in use. Then you have to detect a degenerate case (which is a nightmare in itself, since legitimate cases can alternate rapidly through states that appear degenerate) and 'compact'. I will admit it's ugly all around, though. DS > Mind you, I've been trying to find a way NOT to do it for vnodes > because I would like to be able to free them again. And I'm a > little bit concerned if the zone allocator never frees pages again > because that means that one mistake with a fork(2) and a lot of > RAM (not VM, actual RAM) is tied up until next reboot. > > So if we have decided to make struct proc a stable storage kind of > thing, then holding pointers is perfectly ok (with the addition of > a serial number, p_pid wont do). It is the move to stable storage > that has me concerned. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message