Date: Mon, 22 Sep 1997 13:44:05 -0600 From: "Justin T. Gibbs" <gibbs@plutotech.com> 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 ... Message-ID: <199709221944.NAA29456@pluto.plutotech.com> In-Reply-To: Your message of "Mon, 22 Sep 1997 12:12:59 MDT." <199709221812.MAA01622@rocky.mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> Now depending on how you size your callwheel, h << n. With a MAXUSERS >> of 32, the callwheel is 256 entries big if I recall correctly. > >What is it for a 'typical' workstation, which is the one shipped in >GENERIC using 'maxusers 10'? My memory was failing me, from conf/param.c: #define NPROC (20 + 16 * MAXUSERS) int ncallout = 16 + NPROC; So for GENERIC, ncallout is 196 which is the same as the callwheel size. >> 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. > >'softclock()' is also called with some interrupt() masked as well, isn't >it? 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. >> 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. > >True, but if it's 'worst-case' time happens often enough, we're >penalizing the system *alot* more than during timeout/untimeout, which >happens much less rarely. 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. >The 'gotcha' is that I don't know if this is a 'normal' case, since the >paper didn't test normal cases, but instead did lots of >timeout/untimeouts in a user-land process, which stacks the test data in >favor of the new implementation. If you don't have lots of callouts outstanding, softclock has little to do. In the normal case, you don't have lots of callouts outstanding, so (say 30 out of 196), so the amount of difference in speed is at most (x * list entry traversal time) - list entry traversal time. Most of the time the list to traverse will be empty though. >> >I would like to see some #'s that show us the # & amount of time it >> >takes in section on a 'normal' system, using both approaches. If >> >someone has some good ideas how to do that, I'm willing to learn >> >something and go do it. >> >> Allocate an array of ints of size ncallout. In softclock, increment the >> array entry corresponding to the number of entries traversed in a softclock >> run. By periodically scanning this array, you'll get a good idea of the >> value of 'h' for you system. Add three more ints that count the number of >> invocations of softclock, untimeout, and timeout and you should be able to >> draw conclusions from that. > >But, that doesn't give me any latency #'s for any of the operations. >Knowing how often they are called is one thing, and knowing how many >entries are traversed is good, but *times* are the bigger issue. You can infer times from the other information. As the work performed in softclock is at most O(n), you only have to call either of timeout, or untimeout twice in each 10ms period to know that you've won. >Nate -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations ===========================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709221944.NAA29456>