Hi Mark,
Jon, would you mind to take a look, please? This looks good to me, just one question... On Nov 12 22:03, Mark Geisert wrote: > Commentary wording adjusted to say ProcessorQueueLength counts threads, > not processes. Also mention (upcoming) new tool /bin/loadavg. The > release note for Cygwin 3.5.5 is updated. > > In counting runnable threads, divide by NumberOfProcessors to model > distributing the threads among all processors. Otherwise one gets e.g. > PQLs of 20 or more just running a few lively X applications. These PQLs > vary greatly between kernel stats updates every 16ms, so are very clearly > short-term loads. This change helps reduce jitter in load average > calculations. > > At end of load_init(), obtain and discard the first measure of the > counters to deal with the first call always returning error, no data. > Follow this with a short delay so the next measure actually has data to > report. > > At least one older version of Windows, i.e. Win10 Pro 21H1, has a different > name/location for the '% Processor Time' counter and is missing the > 'Processor Queue Length' counter entirely. Code is changed to support > both possible locations of the former and treat the latter as always > reporting 0.0. > > Reported-by: Mark Liam Brown <brownmarkl...@gmail.com> > Addresses: https://cygwin.com/pipermail/cygwin/2024-August/256361.html > Signed-off-by: Mark Geisert <m...@maxrnd.com> > Fixes: de7f13aa9ace (Cygwin: loadavg: improve debugging of load_init) > > --- > winsup/cygwin/loadavg.cc | 70 ++++++++++++++++++++++++++----------- > winsup/cygwin/release/3.5.5 | 3 ++ > 2 files changed, 52 insertions(+), 21 deletions(-) > > diff --git a/winsup/cygwin/loadavg.cc b/winsup/cygwin/loadavg.cc > index 127591a2e..37da077fb 100644 > --- a/winsup/cygwin/loadavg.cc > +++ b/winsup/cygwin/loadavg.cc > [...] > + /* 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(). If you choose a value of 16 msecs, all Sleep() invocations will run at least 2 clock ticks. Thanks, Corinna
