Hi Corinna,
On 11/18/2024 4:22 AM, Corinna Vinschen wrote:
Hi Mark,
Jon, would you mind to take a look, please?
I appreciate the additional eyes, thanks.
This looks good to me, just one question...
On Nov 12 22:03, Mark Geisert wrote:
[...]
+ /* Delay a short time so PdhCQD in caller will have data to collect */
+ Sleep (16/*ms*/); /* let other procs run; one|more yield()s not enough */
Is there a reason you specificially chose 16 msecs here?
I'm asking because the usual clock tick is roughly 15.x msecs.
Any Sleep() > 0 but < 16 results in a sleep of a single clock tick, i.e.,
15 ms. Occassionally 2 ticks, ~31 msecs, 1 to 5 out of 100 runs.
If you choose a value of 15 msecs, the probability of a Sleep() taking
two ticks is much higher and can be 1 out of 2 Sleep().
^^^^^^
lower, I think
If you choose a value of 16 msecs, all Sleep() invocations will run
at least 2 clock ticks.
This Sleep() is only done once for any program that has called
getloadavg(); it's in an initialization function. So it's just one
delay we're considering here, not anything in a loop.
That said, the idea is to minimize the delay but ensure one scheduler
tick has occurred before this function returns to its caller that tries
to read the counters. I agree with your reasoning that 15ms is better
than 16ms at limiting the delay to one tick. Not perfect (due to
Windows being Windows) but better than 16ms.
I'll make that change in the v3 patch forthcoming.
Thanks & Regards,
..mark
