Hi !
I am pretty skeptical by the hardwired constant of 20 (clockticks). At
the usual/common clock interrupt rate of 100 Hz this is 200ms.
So any nanosleep below 200ms will be a kernel busy loop...
For sleeps less than 1 (at most two) clock ticks this would be a crude
workaround until we have better mechanisms like timed
interrupts/tickless kernel.
With today processors 20ms is a LONG time, busy waiting wastes a lot of
otherwise useful cycles/power. Setting up a timed interrupt should be
well below 100us using todays HW and taking the interrupt also (save for
16MHz 68020 machines and similar ones).
Frank
On 12/09/17 15:48, [email protected] wrote:
On Sun, Jul 02, 2017 at 10:33:58AM +0200, Emmanuel Dreyfus wrote:
but that kind of performance problem could exist in many other softwares.
With Go:
go test -short -v -run=TestWaitGroupMisuse2 -count=5000 sync
Performance was so bad they made a bug report for it (10-100s runtime
vs. 0.2s on linux: https://github.com/golang/go/issues/22944
I initially got units confused and used this, it's not the scheduler
timeslice (20ms) but 20hz. switching to scheduler timeslice made it as
bad as before. (??)
this gets the go example to run in 0.3-0.01 s
Index: kern_time.c
===================================================================
RCS file: /cvsroot/src/sys/kern/kern_time.c,v
retrieving revision 1.189
diff -u -p -r1.189 kern_time.c
--- kern_time.c 11 Nov 2016 15:29:36 -0000 1.189
+++ kern_time.c 9 Dec 2017 14:46:08 -0000
@@ -343,11 +343,12 @@ nanosleep1(struct lwp *l, clockid_t cloc
return error;
}
- /*
- * Avoid inadvertently sleeping forever
- */
- if (timo == 0)
- timo = 1;
+ /* Can't do anything useful in so little time */
+ if (timo < 20) {
+ DELAY(hztoms(timo));
+ return 0;
+ }
+
again:
error = kpause("nanoslp", true, timo, NULL);
if (rmt != NULL || error == 0) {
