From owner-freebsd-current  Mon Sep 22 13:39:06 1997
Return-Path: <owner-freebsd-current>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id NAA17817
          for current-outgoing; Mon, 22 Sep 1997 13:39:06 -0700 (PDT)
Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA17808
          for <current@freebsd.org>; Mon, 22 Sep 1997 13:39:02 -0700 (PDT)
Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130])
	by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id OAA01103;
	Mon, 22 Sep 1997 14:38:47 -0600 (MDT)
Message-Id: <199709222038.OAA01103@pluto.plutotech.com>
X-Mailer: exmh version 2.0zeta 7/24/97
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 ... 
In-reply-to: Your message of "Mon, 22 Sep 1997 14:25:45 MDT."
             <199709222025.OAA02565@rocky.mt.sri.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 22 Sep 1997 14:38:37 -0600
From: "Justin T. Gibbs" <gibbs@plutotech.com>
Sender: owner-freebsd-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>> 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
===========================================