[PATCH] Cygwin: Minor updates to load average calculations

[Mark Geisert]

Hi Brian,

On 10/9/2024 9:36 AM, Brian Inglis wrote:
> Clarity suggestions and questions that could perhaps benefit from more 
> comment:
> 
> On 2024-10-08 23:19, Mark Geisert wrote:
[...]
> 
>>     The number of running processes is estimated as 
>> (NumberOfProcessors) * (%
>> -  Processor Time).  The number of runnable processes is estimated as
>> -  ProcessorQueueLength.
>> +  Processor Time).  The number of runnable threads is estimated as
> 
> This looks weird with arbitrary split then indentation; maybe move at 
> least "(%" to next line, maybe also "*", or the whole expression, and 
> maybe add semantic newlines after the sentences:
> 
>  >   The number of running processes is estimated as NumberOfProcessors *
>  >   % Processor Time.  The number of runnable threads is estimated as
> 
>  >   The number of running processes is estimated as
>  >     NumberOfProcessors * % Processor Time.
>  >   The number of runnable threads is estimated as
>  >    ProcessorQueueLength / NumberOfProcessors.
>  >   The instantaneous load ...

There was a construct like this in an inline comment that I caught, but 
I missed this in top commentary.  Your suggestion reads much better.

>> +  (ProcessorQueueLength) / (NumberOfProcessors).  The "instantaneous" 
>> load
>> +  estimate is taken to be the sum of those two numbers.
> 
> Which two are the values summed: running processes + runnable threads?

The sum of the (product expression) and the (division expression).  Not 
exactly what you said, but something related.  I can/will make it clearer.

> 
>> @@ -62,31 +69,46 @@ static bool load_init (void)
>   +    Sleep (15); /* let other procs run; multiple yield()s aren't 
> enough */
> 
> Why so long - why not clock_/nanosleep for just a 16ms tick or even 1ms, 
> as when system has 1ms multimedia timer ticks enabled by e.g. javascript 
> or ntpd, or possibly set <1ms by some games? Effects on other processes 
> may vary by version.

A good question!  This only happens on load_init(), i.e. the first 
access of the counters by whatever program has called the getloadavg() 
syscall.  Right after the counters have been defined there is no data to 
be read.  Some time in the next 15ms there will be data available, 
because Windows updates all counters every 15ms.  We don't know in 
advance when that will be.  We could have a loop checking for data every 
X ms, but given this code is only run on the first access, just waiting 
15ms guarantees data will be available when load_init() returns to its 
caller.  I can/will add commentary to that effect.

I'll make these changes in a v2 patch.  I'm going to hold off on 
submitting that until I hear whether the technical content is OK.
Thanks for the input,

..mark