From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from re-prd-fep-045.btinternet.com (mailomta29-re.btinternet.com [213.120.69.122]) by sourceware.org (Postfix) with ESMTPS id B05F03858D3C for ; Tue, 17 May 2022 14:48:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B05F03858D3C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dronecode.org.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=dronecode.org.uk Received: from re-prd-rgout-001.btmx-prd.synchronoss.net ([10.2.54.4]) by re-prd-fep-045.btinternet.com with ESMTP id <20220517144828.OTYI3219.re-prd-fep-045.btinternet.com@re-prd-rgout-001.btmx-prd.synchronoss.net> for ; Tue, 17 May 2022 15:48:28 +0100 Authentication-Results: btinternet.com; auth=pass (PLAIN) smtp.auth=jonturney@btinternet.com; bimi=skipped X-SNCR-Rigid: 613A8CC323BFBD48 X-Originating-IP: [86.139.167.41] X-OWM-Source-IP: 86.139.167.41 (GB) X-OWM-Env-Sender: jonturney@btinternet.com X-VadeSecure-score: verdict=clean score=0/300, class=clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgedvfedrheejgdejiecutefuodetggdotefrodftvfcurfhrohhfihhlvgemuceutffkvffkuffjvffgnffgvefqofdpqfgfvfenuceurghilhhouhhtmecufedtudenucenucfjughrpefkffggfgfuvfhfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeflohhnucfvuhhrnhgvhicuoehjohhnrdhtuhhrnhgvhiesughrohhnvggtohguvgdrohhrghdruhhkqeenucggtffrrghtthgvrhhnpeehudeuveeujeeujeegueefhedttdekvedtudeileefteetfeefjeejudekfefggfenucffohhmrghinheptgihghifihhnrdgtohhmnecukfhppeekiedrudefledrudeijedrgedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehhvghloheplgduledvrdduieekrddurddutdehngdpihhnvghtpeekiedrudefledrudeijedrgedupdhmrghilhhfrhhomhepjhhonhdrthhurhhnvgihsegurhhonhgvtghouggvrdhorhhgrdhukhdpnhgspghrtghpthhtohepuddprhgtphhtthhopegthihgfihinhdquggvvhgvlhhophgvrhhssegthihgfihinhdrtghomh X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean Received: from [192.168.1.105] (86.139.167.41) by re-prd-rgout-001.btmx-prd.synchronoss.net (5.8.716.04) (authenticated as jonturney@btinternet.com) id 613A8CC323BFBD48 for cygwin-developers@cygwin.com; Tue, 17 May 2022 15:48:28 +0100 Message-ID: Date: Tue, 17 May 2022 15:48:26 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: load average calculation failing -- fixed by Windows update Content-Language: en-GB 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: Jon Turney In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1193.9 required=5.0 tests=BAYES_00, FORGED_SPF_HELO, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_PASS, 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 14:48:32 -0000 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