From owner-freebsd-current Mon Sep 22 13:13:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA15590 for current-outgoing; Mon, 22 Sep 1997 13:13:33 -0700 (PDT) Received: from usr06.primenet.com (tlambert@usr06.primenet.com [206.165.6.206]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA15582 for ; Mon, 22 Sep 1997 13:13:14 -0700 (PDT) Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id NAA20498; Mon, 22 Sep 1997 13:12:58 -0700 (MST) From: Terry Lambert Message-Id: <199709222012.NAA20498@usr06.primenet.com> 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 To: gibbs@plutotech.com (Justin T. Gibbs) Date: Mon, 22 Sep 1997 20:12:58 +0000 (GMT) Cc: nate@mt.sri.com, gibbs@plutotech.com, bde@zeta.org.au, current@FreeBSD.ORG In-Reply-To: <199709221755.LAA25129@pluto.plutotech.com> from "Justin T. Gibbs" at Sep 22, 97 11:55:12 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > But running time isn't the only thing to consider. As I mentioned > before, untimeout/timeout are often called from an interrupt context > and the old algorithm caused an indeterminate delay in this scenario, > potentially causing problems for that device and any that share the > same interrupt. I still don't agree that this is a good rationale; IMO, the interrupts should be virtualized. I personally would not permit memory allocations to occur at interrupt. The only place this issue is even marginally relevelent is the fastintr code. > You also have to consider that timeout/untimeout calls occur at > indeterminate rates, but softclock runs at a fixed rate meaning that > the amount of work it performs scales better than if that work was > pushed off into either of timeout or untimeout. The softclock code assumes a higher frequency than the relative interval between timer firings. This is bad, expecially if I want a timer of better than 122uS resoloution. I can concieve of valid uses for timers in the 1uS - 500nS range (valid == not just the pc speaker driver). You addreesed the "if an when we want high resoloution timers" issue in another posting, so I won't press a case for it here. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.