Date: Mon, 22 Sep 1997 14:38:37 -0600 From: "Justin T. Gibbs" <gibbs@plutotech.com> To: Nate Williams <nate@mt.sri.com> Cc: "Justin T. Gibbs" <gibbs@plutotech.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: <199709222038.OAA01103@pluto.plutotech.com> In-Reply-To: Your message of "Mon, 22 Sep 1997 14:25:45 MDT." <199709222025.OAA02565@rocky.mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> It runs at splhigh() while traversing callout entries and splsoftclock()
>> when calling timeouts. The new implemenatation will traverse at most
>> 100 entries before lowering it's IPL from splhigh() so that other interrupt
>> handlers can run.
>
>I need to look at the code. Hmm, seems kind of silly to me:
>
> ++steps;
> if (steps >= MAX_SOFTCLOCK_STEPS) {
> nextsoftcheck = c;
> splx(s);
> /* Give hardclock() a chance. */
> s = splhigh();
> c = nextsoftcheck;
> steps = 0;
>
>Does lowering the spl level in between those two lines *really* give
>anything a chance to get work done?
If there are pending hardware interrupts, they will fire at the point of
splx().
>> 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.
>> 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?
>Nate
--
Justin T. Gibbs
===========================================
FreeBSD: Turning PCs into workstations
===========================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709222038.OAA01103>