Date: Wed, 30 Jun 1999 11:35:08 -0700 From: "David Schwartz" <davids@webmaster.com> To: "Poul-Henning Kamp" <phk@critter.freebsd.dk>, "Brian F. Feldman" <green@unixhelp.org> Cc: <cvs-all@FreeBSD.org> Subject: RE: cvs commit: src/sys/kern init_main.c kern_fork.c kern_linker.c vfs_aio.c src/sys/sys proc.h Message-ID: <000001bec327$47da1cd0$021d85d1@youwant.to> In-Reply-To: <43774.930765873@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?000001bec327$47da1cd0$021d85d1>