Date: Mon, 22 Sep 1997 20:41:11 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: nate@mt.sri.com (Nate Williams) Cc: tlambert@primenet.com, gibbs@plutotech.com, nate@mt.sri.com, 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: <199709222041.NAA22085@usr06.primenet.com> In-Reply-To: <199709221932.NAA02277@rocky.mt.sri.com> from "Nate Williams" at Sep 22, 97 01:32:20 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709222041.NAA22085>