Date: Sat, 2 Jun 2012 20:47:36 +0200 From: Davide Italiano <davide.italiano@gmail.com> To: Bruce Evans <brde@optusnet.com.au> Cc: svn-src-projects@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r236449 - projects/calloutng/sys/kern Message-ID: <CACYV=-EE2tfsngxN4U_GFcx-NtKHT3JDF1Qx=zbHN5UEt3U12g@mail.gmail.com> In-Reply-To: <20120602233307.S1957@besplex.bde.org> References: <201206021304.q52D4p2X090537@svn.freebsd.org> <20120602233307.S1957@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jun 2, 2012 at 4:16 PM, Bruce Evans <brde@optusnet.com.au> wrote: > On Sat, 2 Jun 2012, Davide Italiano wrote: > >> Log: >> =A0Replace binuptime() with getbinuptime() because it's suitable for the >> =A0purpose and it's cheaper. Update the relative comment on precision er= ror >> =A0during callwheel scan as well. > > > This makes even less sense than converting to bintimes at all. > getbinuptime() can give an even lower precision than the current timer > ticks, since it is only updated every tc_tick/hz seconds while ticks > are updated every 1/hz seconds. =A0Also, you have to keep timeouts firing > for getbintime() to work. =A0OTOH, bintime() is unusable in timeout code, > since it may be too inefficient, depending on the timecounter hardware. > cpu_ticks() might be usable. =A0It doesn't use bintimes and isn't very > accurate, but these are other bugs which become features for use here. > > >> Modified: projects/calloutng/sys/kern/kern_timeout.c >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> --- projects/calloutng/sys/kern/kern_timeout.c =A0Sat Jun =A02 12:26:14 = 2012 >> =A0 =A0 =A0(r236448) >> +++ projects/calloutng/sys/kern/kern_timeout.c =A0Sat Jun =A02 13:04:50 = 2012 >> =A0 =A0 =A0(r236449) >> @@ -373,9 +373,9 @@ callout_tick(void) >> =A0 =A0 =A0 =A0need_softclock =3D 0; >> =A0 =A0 =A0 =A0cc =3D CC_SELF(); >> =A0 =A0 =A0 =A0mtx_lock_spin_flags(&cc->cc_lock, MTX_QUIET); >> - =A0 =A0 =A0 binuptime(&now); >> + =A0 =A0 =A0 getbinuptime(&now); >> =A0 =A0 =A0 =A0/* >> - =A0 =A0 =A0 =A0* Get binuptime() may be inaccurate and return time up = to 1/HZ in >> the past. >> + =A0 =A0 =A0 =A0* getbinuptime() may be inaccurate and return time up t= o 1/HZ in >> the past. >> =A0 =A0 =A0 =A0 * In order to avoid the possible loss of one or more eve= nts look >> back 1/HZ >> =A0 =A0 =A0 =A0 * in the past from the time we last checked. >> =A0 =A0 =A0 =A0 */ > > > Up to tc_tick/hz, not up to 1/HZ. =A0tc_tick is the read-only sysctl > variable kern.timecounter.tick that is set to make tc_tick/hz as close > to 1 msec as possible. =A0If someone asks for busy-waiting by setting > HZ to much larger than 1000 and uses this to generate lots of timeouts, > they probably get this now, but get*time() cannot be used even to > distingish times differing by the timeout granularity. =A0It is hard to > see how it could ever work for the above use (timout scheduling with > a granularity of ~1/hz when you can only see differences of ~tc_tick/hz, > with tc_tick quite often 4-10, or 100-1000 to use or test corner > cases??). =A0With a tickless kernel, timeouts wouldn't have a fixed > granularity, but you need accurate measurements of times even more. > One slow way to get them is to call binuptime() again in the above. > Another, even worse way to update timecounters after every timeout > expires (the update has a much higher overhead than binuptime(), so > this will be very slow iff timeouts that expire are actually used). > > I noticed too many style bugs to describe in previous changes in this > area. =A0The above only shows formatting for 85-column terminals. Bruce, I'm happy you looked at my commit, and I'm ready to look to fix them if you want to help me notifying where I'm wrong with style. > > Bruce Davide
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACYV=-EE2tfsngxN4U_GFcx-NtKHT3JDF1Qx=zbHN5UEt3U12g>