From owner-freebsd-hackers Fri Apr 20 0:34: 9 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id BD21637B43C for ; Fri, 20 Apr 2001 00:34:05 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f3K7Y5E01377 for hackers@freebsd.org; Fri, 20 Apr 2001 00:34:05 -0700 (PDT) Date: Fri, 20 Apr 2001 00:34:05 -0700 From: Alfred Perlstein To: hackers@freebsd.org Subject: junior kernel hacker assignment. Message-ID: <20010420003405.B595@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-all-your-base: are belong to us. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG From time to time I see Poul-Henning post a junior hacker assignment to this list, so I figured I'd make the same use of the bandwidth and mindshare. A while back OpenBSD "optimized" thier implementation of fdalloc() buy using a complex two level bitmask to track open slots in the descriptor table. After the implementation was ported to FreeBSD it was discovered that it actually had a negative impact on performance as world builds seemed to slow down slightly. An alternative possible optimization would be to overload the fd_ofiles array to also be a union of pointers to empty slots in the fd_ofiles array. It's not as easy as it sounds because you must make it into a doubly linked list so that entries can be removed from arbitrary locations so the freelist is kept consistant. Another trick could be overloading the fd_ofileflags to be the corresponding back-pointer, this would require that both arrays fd_ofiles and fd_ofileflags become unions and it would bloat fd_ofileflags by 4x, but that would save 25% of the bloat of doubling the size requirement of fd_ofiles. If anyone wants to take a crack at doing this it'd be interesting to see the results. I know it will cost at least doubling the size of fd_ofiles, but the speed of lookups especially for programs with a large amount of open files could be signifigant. -- -Alfred Perlstein - [alfred@freebsd.org] Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message