Date: Sun, 21 Sep 1997 23:48:42 -0600 From: "Justin T. Gibbs" <gibbs@plutotech.com> To: Nate Williams <nate@mt.sri.com> Cc: "Justin T. Gibbs" <gibbs@plutotech.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 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: <199709220548.XAA08824@pluto.plutotech.com> In-Reply-To: Your message of "Sun, 21 Sep 1997 23:05:20 MDT." <199709220505.XAA29116@rocky.mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>I just read the paper, and it's interesting, but they never give results >based on what the kernel does now. Basically, it's pretty easy to say >that registering/unregistering timers is now much faster, but given that >things can take longer in softclock(), it's not obvious (at least to me) >that this is a win overall, since we call softlock a *heck* of alot more >than we register/de-register timeout/callouts. The trick is determining what the largest hash chain length is and then you'll know your answer. As the hash table size is the same as the number of callouts initially allocated, and the hash function should offer a fairly good distribution, it seems that softclock shouldn't have that much extra work to do. In the case of SCSI disk I/O, the common case is that the timeout never expires and the I/O completes in less than 10 ticks, so softclock will decrement that callout's counter at most once before it's removed. In performing the conversion of all the client code, it became quite obvious that the common case is to schedule a timeout that will be canceled before it expires and that the lifetime of a timeout is quite short. If this continues to be the case, we'll be bounded by the insert and removal time, not by the work in softclock as a single callout entry will be inserted and removed multiple times during one rotation of the callwheel. >Does anyone have insight they're willing to share, since the author's >did prove they accomplished what they set out to do, but it didn't >really give me a warm-fuzzy that it would help improve performance. Take a server with 10 Seagate disks. Each one of these disks can handle 63 transactions at a time. If you split the disks across controllers correctly, you can readily keep them saturated with requests. Thats 630 pending callouts and an O(n) hit for insert and removal. Add to that any process alarm timers, the network stack's timer, the serial ports timeout or two, etc. It really adds up and it defenitly shows up in profiles. >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?199709220548.XAA08824>