Date: Mon, 22 Sep 1997 20:12:58 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: gibbs@plutotech.com (Justin T. Gibbs) Cc: nate@mt.sri.com, gibbs@plutotech.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: <199709222012.NAA20498@usr06.primenet.com> In-Reply-To: <199709221755.LAA25129@pluto.plutotech.com> from "Justin T. Gibbs" at Sep 22, 97 11:55:12 am
next in thread | previous in thread | raw e-mail | index | archive | help
> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709222012.NAA20498>