From owner-freebsd-current Mon Sep 22 11:39:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA07783 for current-outgoing; Mon, 22 Sep 1997 11:39:56 -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 LAA07778 for ; Mon, 22 Sep 1997 11:39:53 -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 MAA14230; Mon, 22 Sep 1997 12:39:45 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id MAA01809; Mon, 22 Sep 1997 12:39:44 -0600 (MDT) Date: Mon, 22 Sep 1997 12:39:44 -0600 (MDT) Message-Id: <199709221839.MAA01809@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 , 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: <199709220548.XAA08824@pluto.plutotech.com> References: <199709220505.XAA29116@rocky.mt.sri.com> <199709220548.XAA08824@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 > In performing the conversion of all the client code, it became quite > obvious that the common case is to schedule a timeout that will be > canceled before it expires and that the lifetime of a timeout is quite > short. Is 'short' shorter than a single softclock()? If not, then we still need to do more work than we used to do. And, if we have 2 ticks, 'assuming all things we're equal' the new code could be the same speed as the old code. (Obviously bogus explanation follows): Old code: 1) timeout = O(x) ~= 10 seconds 2) untimeout = O(x) ~= 10 seconds 3) softclock = O(1) ~= 1 second So, assuming we call a timeout, get 2 softclock updates, and then call untimeout we get: 10 + 1 + 1 + 10 = 22 seconds. New code: 1) timeout = O(1) ~= 1 seconds 2) untimeout = O(1) ~= 1 seconds 3) softclock = O(n) ~= 10 second The same as above: 1 + 10 + 10 + 1 = 22 seconds. Again, this is so obviously bogus that I hate to even mention it, but it explains what I'm trying to say. Depending on *how often* and *how long* each of the operations takes, the new solution may not be a win. I'll stop for now, since this is as much a learning experience for me as anything, and I don't want to wear out my welcome. :) :) Nate