From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from m0.truegem.net (m0.truegem.net [69.55.228.47]) by sourceware.org (Postfix) with ESMTPS id 269113858C51 for ; Tue, 17 May 2022 19:48:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 269113858C51 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=maxrnd.com Authentication-Results: sourceware.org; spf=none smtp.mailfrom=maxrnd.com Received: (from daemon@localhost) by m0.truegem.net (8.12.11/8.12.11) id 24HJmkGf083755 for ; Tue, 17 May 2022 12:48:46 -0700 (PDT) (envelope-from mark@maxrnd.com) Received: from 162-235-43-67.lightspeed.irvnca.sbcglobal.net(162.235.43.67), claiming to be "[192.168.1.100]" via SMTP by m0.truegem.net, id smtpd2zrKDK; Tue May 17 12:48:37 2022 Subject: Re: load average calculation failing -- fixed by Windows update To: cygwin-developers@cygwin.com References: <3a3edd10-2617-0919-4eb0-7ca965b48963@maxrnd.com> <223aa826-7bf9-281a-aed8-e16349de5b96@dronecode.org.uk> <53664601-5858-ffd5-f854-a5c10fc25613@maxrnd.com> <670cea06-e202-3c90-e567-b78d737f5156@dronecode.org.uk> <2c7d326d-3de0-9787-897f-54c62bf3bbcc@maxrnd.com> From: Mark Geisert Message-ID: <2fc2e3ca-c5e3-033f-4b85-f2db47d83bea@maxrnd.com> Date: Tue, 17 May 2022 12:48:37 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.4 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: cygwin-developers@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Cygwin core component developers mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2022 19:48:54 -0000 Jon Turney wrote: > On 13/05/2022 12:05, Corinna Vinschen wrote: >> On May 13 13:04, Corinna Vinschen wrote: >>> On May 13 11:34, Jon Turney wrote: >>>> On 12/05/2022 10:48, Corinna Vinschen wrote: >>>>> On May 11 16:40, Mark Geisert wrote: >>>>>> >>>>>> The first counter read now gets error 0xC0000BC6 == PDH_INVALID_DATA, but no >>>>>> errors on subsequent counter reads.  This sounds like it now matches what >>>>>> Corinna reported for W11.  I wonder if she's running build 1706 already. >>>>> >>>>> Erm... looks like I didn't read your mail throughly enough. >>>>> >>>>> This behaviour, the first call returning with PDH_INVALID_DATA and only >>>>> subsequent calls returning valid(?) values, is what breaks the >>>>> getloadavg function and, consequentially, /proc/loadavg.  So maybe xload >>>>> now works, but Cygwin is still broken. >>>> >>>> The first attempt to read '% Processor Time' is expected to fail with >>>> PDH_INVALID_DATA, since it doesn't have a value at a particular instant, but >>>> one averaged over a period of time. >>>> >>>> This is what the following comment is meant to record: >>>> >>>> "Note that PDH will only return data for '% Processor Time' after the second >>>> call to PdhCollectQueryData(), as it's computed over an interval, so the >>>> first attempt to estimate load will fail and 0.0 will be returned." >>> >>> But. >>> >>> Every invocation of getloadavg() returns 0.  Even under load.  Calling >>> `cat /proc/loadavg' is an excercise in futility. >>> >>> The only way to make getloadavg() work is to call it in a loop from the >>> same process with a 1 sec pause between invocations.  In that case, even >>> a parallel `cat /proc/loadavg' shows the same load values. >>> >>> However, as soon as I stop the looping process, the /proc/loadavg values >>> are frozen in the last state they had when stopping that process. >> >> Oh, and, stopping and restarting all Cygwin processes in the session will >> reset the loadavg to 0. >> >>> Any suggestions how to fix this? > > Ah, right.  'while true ; do cat /proc/loadavg ; done', just shows a stream of > zeroes, because each process only calls getloadavg() once, which doesn't update > the loadavg, because the first call to fetch it fails PDH_INVALID_DATA. > > This isn't really simply fixable because PDH "handles" aren't shareable between > processes. > > I don't think this is new since it is mentioned in [1]. > > Non-solution: use top instead :) > > [1] https://cygwin.com/pipermail/cygwin-patches/2017q1/008699.html I think my starting the "imperfections" thread only fractured the discussion :-(. The patch I mention in the other thread improves this repeated cat /proc/loadavg display, if nothing else. It throws away that first sample that errors. ~ while true; do cat /proc/loadavg; done 0.00 0.00 0.00 1/10 0.00 0.00 0.00 1/10 0.00 0.00 0.00 1/10 0.00 0.00 0.00 1/10 0.00 0.00 0.00 1/10 0.00 0.00 0.00 1/10 0.00 0.00 0.00 1/10 0.00 0.00 0.00 1/10 0.00 0.00 0.00 1/10 0.00 0.00 0.00 1/10 0.00 0.00 0.00 1/10 0.00 0.00 0.00 1/10 0.00 0.00 0.00 1/10 0.08 0.01 0.00 1/10 0.08 0.01 0.00 1/10 0.08 0.01 0.00 1/10 0.08 0.01 0.00 1/10 0.08 0.01 0.00 1/10 0.08 0.01 0.00 1/10 0.08 0.01 0.00 1/10 0.08 0.01 0.00 1/10 0.08 0.01 0.00 1/10 0.08 0.01 0.00 1/10 0.08 0.01 0.00 1/10 0.08 0.01 0.00 1/10 0.08 0.01 0.00 1/10 0.08 0.01 0.00 1/10 0.07 0.01 0.00 1/10 0.07 0.01 0.00 1/10 0.07 0.01 0.00 1/10 ... ..mark