Date: Wed, 24 Sep 1997 05:34:01 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: gibbs@plutotech.com (Justin T. Gibbs) Cc: tlambert@primenet.com, gibbs@plutotech.com, nate@mt.sri.com, 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 Message-ID: <199709240534.WAA03106@usr07.primenet.com> In-Reply-To: <199709231919.NAA28306@pluto.plutotech.com> from "Justin T. Gibbs" at Sep 23, 97 01:19:15 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >Ugh. What I meant to say was that the number of entries outstanding > >at one time relative to the number of insertions and deletions that > >take place is small in proportion to the number of hash buckets. This > >would make it relatively rare that a softclock would ever hit an entry. > >It was this rarity I meant to reference, but my fingers were too fast. > > I don't know how rare it is really. You'd have to do some statistics > relating which bucket softclock is currently looking at and the likelihood > of a new timeout being scheduled "close" to that position. I do know that > it is going to be quite rare to have a callout touched more than once > during it's lifetime. 256 ticks is a long time. 1024 ticks is even > longer. Except if I want to up the rate at which softclock fires, which would make the wheel spin faster and the entries live for more softclock ticks, but no more absolute time. 8-(. I suppose you could up the hash size for this, but I like the idea of a sorted and unsorted queue head per bucket better. It solved both problems at the same time, and still lets me up softclock at some later time to get HRT without a massive penalty. All in all, I'd say that this has been a very productive discussion; it would have been a hell of a lot more productive if everyone was in the same room with a whiteboard (8-)), but it's a hell of a lot better than the "inane let's pick a new name for tetris" discussion that resulted from my unfortunate use of an example name in my suggested Makefile fix. Regards, 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?199709240534.WAA03106>