Date: Mon, 22 Sep 1997 10:30:40 -0600 (MDT) From: Nate Williams <nate@mt.sri.com> To: "Justin T. Gibbs" <gibbs@plutotech.com> Cc: Bruce Evans <bde@zeta.org.au>, current@freebsd.org, nate@mt.sri.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 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: <199709221630.KAA01072@rocky.mt.sri.com> In-Reply-To: <199709221616.KAA18273@pluto.plutotech.com> References: <199709221553.BAA20408@godzilla.zeta.org.au> <199709221616.KAA18273@pluto.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> >>How much storage do I need in order to realloc the arrays? Is it bounded? > > > >No, but it is too small to matter. 63 transactions on each of 520 drives > >can be supported using just two blocks of size 4K. Each queue entry takes > >only 2 bits. This is 96 times denser than the current callout table. > > And runs in roughly O(n) time every time the interval timer expires. Except that processing a tick now runs O(n), where n is the # of elements in the callout wheel (which gets pretty big when you have 630 callouts in your example above, since the initial size of the callout wheel is set), so I still don't see a big win. I'm not saying that it's any worse/better than the existing scheme, in fact I don't see a win. Stating that it takes O(n) times to add/remove a callout and calling it a win when it takes O(n) time to process a tick isn't a win in my book. PHK answered by saying that on his laptop, it seemed to be a wash, so that's encouraging, but it seems to have the ability to make the system slower. (I'd like to see how PHK compared the two approaches.) Finally, you'll notice that I'm not proposing the we rip out the new solution (since I have nothing better to propose, although the original solution could be sped up by adding the setcallout()/unsetcallout() additions w/out the call wheel). I just want to understand *why* it's making things better for the average user, since the average user doesn't have > 10 drives running tags. Penalizing the 'extreme' user doesn't seem to be a big win in my book. In summary, all of the operations are called 'often'. 1) clock ticks 2) registering timeouts 3) de-registering timeouts 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. Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709221630.KAA01072>