On Fri, Dec 04, 2020 at 09:56:02AM +0100, Claudio Jeker wrote:
> On Thu, Dec 03, 2020 at 10:05:30PM -0600, Scott Cheloha wrote:
> > Hi,
> >
> > srp_finalize(9) uses tsleep(9) to spin while it waits for the object's
> > refcount to reach zero. It blocks for up to 1 tick and then checks
> > the refecount again and again.
> >
> > We can just as easily do this with tsleep_nsec(9) and block for 1
> > millisecond per interval.
> >
> > ok?
> >
> > Index: kern_srp.c
> > ===================================================================
> > RCS file: /cvs/src/sys/kern/kern_srp.c,v
> > retrieving revision 1.12
> > diff -u -p -r1.12 kern_srp.c
> > --- kern_srp.c 8 Sep 2017 05:36:53 -0000 1.12
> > +++ kern_srp.c 4 Dec 2020 04:04:39 -0000
> > @@ -274,7 +274,7 @@ void
> > srp_finalize(void *v, const char *wmesg)
> > {
> > while (srp_referenced(v))
> > - tsleep(v, PWAIT, wmesg, 1);
> > + tsleep_nsec(v, PWAIT, wmesg, MSEC_TO_NSEC(1));
> > }
> >
> > #else /* MULTIPROCESSOR */
> >
>
> Why only 1ms instead of the original 10ms (at least on most archs)?
The underlying implementation can only process timeouts from
hardclock(9) which runs about hz times per second. If we tell the
thread to "sleep for 10ms" it's almost always going to overshoot the
next hardclock(9) and wind up sleeping ~20ms.
Some people run with HZ=1000 kernels. I don't think many people run
with kernels with a higher HZ than that, though. So I figure a 1ms
sleep is "good enough" for all practical kernels. On HZ=100 kernels
the thread will oversleep because it doesn't process timeouts often
enough to honor the 1ms request.
Basically I'm trying to pick a reasonable polling interval (not too
fast) that also won't cause the existing default kernel to block for
longer than it already does (~10ms). The default kernel is HZ=100, so
a 1ms sleep will, in this case, almost always sleep ~10ms per
iteration of this loop.
It's a bit of a chicken-and-egg problem.
Does that make any sense?
