From owner-freebsd-current Mon Sep 22 14:34:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA22363 for current-outgoing; Mon, 22 Sep 1997 14:34:21 -0700 (PDT) Received: from ns.mt.sri.com (SRI-56K-FR.mt.net [206.127.65.42]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA22355 for ; Mon, 22 Sep 1997 14:34:17 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.7/8.8.7) with ESMTP id PAA15552; Mon, 22 Sep 1997 15:34:05 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id PAA03250; Mon, 22 Sep 1997 15:34:03 -0600 (MDT) Date: Mon, 22 Sep 1997 15:34:03 -0600 (MDT) Message-Id: <199709222134.PAA03250@rocky.mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Justin T. Gibbs" Cc: Nate Williams , Bruce Evans , current@freebsd.org Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 src/sys/i386/eisa 3c5x9.c aha1742.c aic7770.c bt74x.c eisaconf.c eisaconf.h if_fea.c if_vx_eisa.c src/sys/i386/i386 autoconf.c ... In-Reply-To: <199709222129.PAA02701@pluto.plutotech.com> References: <199709222113.PAA03063@rocky.mt.sri.com> <199709222129.PAA02701@pluto.plutotech.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >If that changes, then my analysis of the code suggests that the current > >scheme could be a deteriment, rather than a help if we implement high > >resolution timers, because the time in softclock() becomes dominant > >instead of the time in timeout/untimeout. Simply put, if softclock is > >called more than timeout/untimeout, then the new system is a lose. (No > >matter how many callouts are outstanding.) > > If we implement high resolution timers, we will probably pay the O(hash > chain length) insertion sort price in timeout and schedule a one shot > timer for the next event that needs to run meaning that softclock is no > longer tied to hz. Then, why implement the darn thing at all, when we could simply add a hash-table to make untimeout more effecient, and not lose backwards compatability with all of the BSD code? I don't see what else the new code buys us that couldn't be done simply and with less overhead (in terms of code and new structure overhead)? Then, we'd be O(n) for timeout, O(1) for softclock, and O(1) for untimeout, which would be the same but with complete backwards compatability. The best of both worlds. :) Nate