Date: Mon, 22 Sep 1997 13:05:28 -0600 (MDT) From: Nate Williams <nate@mt.sri.com> To: "Justin T. Gibbs" <gibbs@plutotech.com> Cc: Terry Lambert <tlambert@primenet.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: <199709221905.NAA02100@rocky.mt.sri.com> In-Reply-To: <199709221559.JAA17865@pluto.plutotech.com> References: <199709220647.XAA16869@usr07.primenet.com> <199709221559.JAA17865@pluto.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> >A more deterministic implementation would associate an absolute tick > >value (rather than a count) with each entry, and insert entries in > >sorted order. > > 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. > Softclock has the luxury of lowering it's spl at deterministic intervals > (see the implementation) while a caller from an interrupt context doesn't. > the current implementation always blocks interrupts for a deterministic > amount of time. What you propose doesn't. >From reading the papers, the performance would be neglidgable (sp?) since they assume the hash chain length is <= 1. That's one of the performance gains they assume. > Even so, it is probably better to store an absolute tick value regardless > so that you don't have to perform the subtraction. A substraction is *dirt cheap* to do. Finding the element on the list is much more expensive than the subtraction. Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709221905.NAA02100>