From owner-freebsd-current Mon Sep 22 19:19:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA08588 for current-outgoing; Mon, 22 Sep 1997 19:19:05 -0700 (PDT) Received: from usr01.primenet.com (tlambert@usr01.primenet.com [206.165.6.201]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA08583 for ; Mon, 22 Sep 1997 19:19:02 -0700 (PDT) Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id TAA00259; Mon, 22 Sep 1997 19:18:48 -0700 (MST) From: Terry Lambert Message-Id: <199709230218.TAA00259@usr01.primenet.com> 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 To: nate@mt.sri.com (Nate Williams) Date: Tue, 23 Sep 1997 02:18:47 +0000 (GMT) Cc: gibbs@plutotech.com, nate@mt.sri.com, bde@zeta.org.au, current@FreeBSD.ORG In-Reply-To: <199709222113.PAA03063@rocky.mt.sri.com> from "Nate Williams" at Sep 22, 97 03:13:52 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > The code assumes nothing of the sort. My analysis of running time assumes > > that the frequency of calls to timeout or untimeout is >= the number of > > calls to softclock. > > 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.) I think queueing the sorted insertion handles all of these cases (see other posting). It makes calling timeout() O(1), calling untimeout O(1), and leaves the traversal O(1 + (number of new timers)/2). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.