Date: Tue, 23 Sep 1997 02:18:47 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: nate@mt.sri.com (Nate Williams) Cc: gibbs@plutotech.com, nate@mt.sri.com, bde@zeta.org.au, 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 Message-ID: <199709230218.TAA00259@usr01.primenet.com> In-Reply-To: <199709222113.PAA03063@rocky.mt.sri.com> from "Nate Williams" at Sep 22, 97 03:13:52 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709230218.TAA00259>