Date: Mon, 22 Sep 1997 15:34:03 -0600 (MDT) From: Nate Williams <nate@mt.sri.com> To: "Justin T. Gibbs" <gibbs@plutotech.com> Cc: Nate Williams <nate@mt.sri.com>, Bruce Evans <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 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 ... Message-ID: <199709222134.PAA03250@rocky.mt.sri.com> In-Reply-To: <199709222129.PAA02701@pluto.plutotech.com> References: <199709222113.PAA03063@rocky.mt.sri.com> <199709222129.PAA02701@pluto.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> >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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709222134.PAA03250>