Re: load average calculation failing

[Mark Geisert <mark@maxrnd.com>]

Corinna Vinschen wrote:
> [redirect back to cygwin-developers]
> 
> On May  8 11:27, Jon Turney wrote:
>> On 08/05/2022 08:01, Mark Geisert wrote:
>>> Mark Geisert wrote (on the main Cygwin mailing list):
>>>> I've recently noticed that the 'xload' I routinely run shows zero
>>>> load even with compute-bound processes running.  This is on both
>>>> Cygwin pre-3.4.0 as well as 3.3.4.  A test program, shown below,
>>>> indicates that getloadavg() is returning with 0 status, i.e. not an
>>>> error but no elems
>>>> of the passed-in array updated.
>>>>
>>>> Stepping with gdb through the test program seems weird within the
>>>> loadavginfo::load_init method.  Single-stepping at line
>>>> loadavg.cc:68 goes to strace.h:52 and then to _sigbe ?!
>>>>
>>>> I had recently updated both Cygwin and Windows 10 to latest at the
>>>> same time so I cannot say when the failure started.  Last day or two
>>>> at most.
>>>>
>> [...]
>>>
>>> I've debugged a bit further..  Within Cygwin's loadavg.cc:load_init(),
>>> the PdhOpenQueryW() call returns successfully.  The subsequent
>>> PdhAddEnglishCounterW() call is unsuccessful.  It returns status
> 
> This is a bit weird.  I tried to debug this for a while on Friday on
> W11 and on W11 I can reproduce *a* problem, too, just not the same you
> report here.
> 
> On W11 I see load_init() working fine, the calls to
> PdhAddEnglishCounterW succeed.  But then the call to
> PdhGetFormattedCounterValue in get_load() fails with error
> PDH_INVALID_DATA.  The CStatus member of fmtvalue1 is set to
> PDH_CSTATUS_NO_INSTANCE.
> 
> If I tweak get_load to call PdhCollectQueryData again after a fail,
> the second call succeeds.  The only problem with this is, the returned
> data doesn't make a lot of sense. It only starts to make sense if I
> add a Sleep(1000) before the second PdhCollectQueryData call, which is
> rather disappointing.
> 
> Jon, would it, perhaps, make sense to call PdhCollectQueryData in
> load_init(), without actually checking the return value?  The idea is,
> to make sure to have a base for the next call to PdhCollectQueryData
> from inside load_init.
> 
> But even then, the first values returned by getloadavg might not make
> much sense, so I guess this is just clutching for straws...
> 
>>> 0x800007D0 == PDH_CSTATUS_NO_MACHINE. The code (at line 68 mentioned
> 
> This is a weird error.
> 
>    "The path did not contain a computer name and the function was unable
>     to retrieve the local computer name."
> 
> Yeah, sure.
> 
> Mark, did you try to add the computer name to the path by calling
> GetComputerName() in load_init?

I tried more ham-handedly by prepending L"\\\\hostname" or L"\\\\.".  No change.
I'm running W10 21H2 on my home machines.  One with the issue is up-to-date with 
Windows patches.  Another that still shows reasonable load averages may not have 
the very latest patches; I need to verify that.

Some web page I found while searching for PDH stuff claimed that the performance 
counters are maintained by a Windows Service, which only gets started when some 
process attaches to pdh.dll.  I have to find that page again and see if it talks 
about which Windows versions that applies to.  That might possibly explain why one 
can't get reasonable counter numbers immediately after PdhOpenQuery.  But then, my 
running xload, which does load pdh.dll, should be seeing good counters.

..mark