From owner-freebsd-hackers Thu Jul 8 0: 4: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from not.demophon.com (ns.demophon.com [193.65.70.13]) by hub.freebsd.org (Postfix) with ESMTP id 6214015273 for ; Thu, 8 Jul 1999 00:03:56 -0700 (PDT) (envelope-from will@not.demophon.com) Received: (from will@localhost) by not.demophon.com (8.9.3/8.8.7) id JAA18054; Thu, 8 Jul 1999 09:59:17 +0300 (EEST) (envelope-from will) To: dillon@apollo.backplane.com (Matthew Dillon) Cc: hackers@freebsd.org Subject: Re: Heh heh, humorous lockup References: <199907080003.RAA95132@apollo.backplane.com> From: Ville-Pertti Keinonen Date: 08 Jul 1999 09:59:17 +0300 In-Reply-To: dillon@apollo.backplane.com's message of "8 Jul 1999 03:05:23 +0300" Message-ID: <86n1x7r5iy.fsf@not.demophon.com> Lines: 30 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG dillon@apollo.backplane.com (Matthew Dillon) writes: > pair-down the fields in both structures. For example, the vnode structure > contains a lot of temporary clustering fields that could be removed > entirely if clustering operations are done at the time of the actual I/O > rather then before hand ( which leads to other problems related to > low-memory deadlocks :-(... but assuming that could be fixed... ). Actually the vnode structure can be reduced in size quite a bit without affecting behavior. I analyzed this in a private mail to phk a few months ago, I can get the list of necessary changes out again if anyone is actually interested. The idea was to reduce the size to 128 bytes (on i386) so that the kernel malloc would do a reasonable job allocating the vnodes without too much overhead. IIRC it was very close. I had written code that allocated and deallocated vnodes dynamically (see http://www.hut.fi/~will/freebsd_vnfree0.diff for a non-malloc version with parameters adjusted to exercise the behavior quite heavily). It didn't seem like a very useful feature, though, because of fragmentation (even with the 'optimizing' zone allocator in the patch). Even if the kernel malloc would be usable, the only other common object that would typically use that memory would be ffs inodes, which are allocated and deallocated along with vnodes... This reminds me - the small patch I submitted to fix the v_id references still hasn't been commited (phk, if you're reading this, is there any specific reason for this?). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message