From owner-freebsd-current Mon Sep 22 13:47:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA18459 for current-outgoing; Mon, 22 Sep 1997 13:47:09 -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 NAA18452 for ; Mon, 22 Sep 1997 13:47:05 -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 OAA15169; Mon, 22 Sep 1997 14:46:59 -0600 (MDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id OAA02778; Mon, 22 Sep 1997 14:46:57 -0600 (MDT) Date: Mon, 22 Sep 1997 14:46:57 -0600 (MDT) Message-Id: <199709222046.OAA02778@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: <199709222038.OAA01103@pluto.plutotech.com> References: <199709222025.OAA02565@rocky.mt.sri.com> <199709222038.OAA01103@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 > >> Although this may be true today, the point about it scaling still holds > >> true. If you increase the frequency of untimeout/timeout calls, the > >> new system scales very well in that the you will still encounter your > >> 'worst-case' time at the same rate as you did originally. > > > >Assuming the frequency of the corresponding timeout/untimeout calls is > >greater than the clock frequence, yes. However, if the frequency of > >when you call timeout and the corresponding untimeout is less than the > >frequency of softclock, it's a lose compared to the original > >implementation. With the low frequency of softclock, I suspect it's now > >an 'overall' win. > > The timeout and untimeout calls do not need to be paired for this to be > the case. Sure they do. If you have a bunch of timeout calls, and the untimeouts for them don't occur until *after* softclock, you have lots of entries to walk through. > >> If you don't have lots of callouts outstanding, softclock has little to > >> do. > > > >In it's current implementation, doesn't it have to decrement every item > >on the list, thus is has to walk and modify *every* callout in the list? > > But what is in the list if few callouts are outstanding? The whole assumption of this code is that the frequency of paird timeout/untimeout calls happen *much* more frequently than the frequency of softclocks, right? If that isn't the case (the clock frequency is increased, or timeouts are long), then the new system is a lose, because the # of callouts in the list at softclock() time starts to effect the effeciency of the system. Is this a correct assumption? If so, then Terry's concerns about high-resolution timers is still valid, even though the design wasn't designed for this, it negatively affects it *IF* high-resolution timers are a future goal. Nate