From owner-freebsd-current Mon Sep 22 13:41:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA18078 for current-outgoing; Mon, 22 Sep 1997 13:41:25 -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 NAA18073 for ; Mon, 22 Sep 1997 13:41:23 -0700 (PDT) Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id NAA22085; Mon, 22 Sep 1997 13:41:12 -0700 (MST) From: Terry Lambert Message-Id: <199709222041.NAA22085@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: nate@mt.sri.com (Nate Williams) Date: Mon, 22 Sep 1997 20:41:11 +0000 (GMT) Cc: tlambert@primenet.com, gibbs@plutotech.com, nate@mt.sri.com, current@FreeBSD.ORG In-Reply-To: <199709221932.NAA02277@rocky.mt.sri.com> from "Nate Williams" at Sep 22, 97 01:32:20 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > More deterministic for who? This trades O(1) insertion for O(hash chain > > > length) insertion so that softclock will become O(timeouts for the current > > > tick). As timeout often is called from an interrupt context > > > it is not so clear where it is better to pay the price of non-determinism. > > > > I'm not so sure timeouts should be called from an interrupt context, > > ever. > > [ rest deleted ] > > We're talking reality here Terry, not theory. > > 'If the world were a perfect place, we wouldn't need interrupts since we > could get everything done when we needed to and it wouldn't mess with > anything else, but this isn't a perfect world.' This is not what I'm saying. I'm saying virtualize the interrupts to reduce the time between when I can want to context switch, and when I can context switch. The more time I spend at interrupt, the less useful work I can do, and the higher my overall latency to get from what I am doing to what I need to be doing instead because of hard time constraints. Most modern UNIX OS's virtualize interrupts as part of supporting RT scheduling. > The extra complexity required to do your above solution is *WAY* > overkill. (I've done things such as it on a small-scale basis, and > performance starts to drop off quickly due to data synchronization when > you have lots of 'objects/drivers'.) Concurrency is only a big win for really cruddy hardware, like QIC-40/80 tape drives and the floppy controller, or anthing that needs PIO'ed. I admit a lot of PC hardware falls in this category. For the SVR3.2 ft driver, fully 40% of the CPU time was sucked up by buzz-loops. The win here is that you can make the CPU available to those devices "in time". This allows you to go off and do other stuff "less important" than buzz-looping in a floppy tape driver. The real win is the ability to set hard deadlines for a context switch for a deadlined event: a move toward hard RT. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.